Suggestions for procedure going forward
We have had a number of ASDF 3 releases that have mostly been aimed at bug-fixing (although some new features have crept in). I'd like to declare ASDF 3 feature complete and done, but I don't want to close the door to future bug fix releases as needed, nor do I want to shove incomplete new features out in order to get bug fixes out. So I'd like to split ASDF development into stable and testing or something like that. Does anyone have experience doing that? If so, please post suggestions for process to ASDF-devel. Thanks! r
On Tue, 2015-11-17 at 11:11 -0600, Robert Goldman wrote:
We have had a number of ASDF 3 releases that have mostly been aimed at bug-fixing (although some new features have crept in).
I'd like to declare ASDF 3 feature complete and done, but I don't want to close the door to future bug fix releases as needed, nor do I want to shove incomplete new features out in order to get bug fixes out.
One suggestion I have before doing that is to remove the whole upgrading mechanism. The purpose of it was to allow loading ASDF3 over ASDF 1/2 when the various implementations were only shipping with the latter, but IMO it's now just a burden. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
On 11/17/15 Nov 17 -4:00 PM, Stelian Ionescu wrote:
On Tue, 2015-11-17 at 11:11 -0600, Robert Goldman wrote:
We have had a number of ASDF 3 releases that have mostly been aimed at bug-fixing (although some new features have crept in).
I'd like to declare ASDF 3 feature complete and done, but I don't want to close the door to future bug fix releases as needed, nor do I want to shove incomplete new features out in order to get bug fixes out.
One suggestion I have before doing that is to remove the whole upgrading mechanism. The purpose of it was to allow loading ASDF3 over ASDF 1/2 when the various implementations were only shipping with the latter, but IMO it's now just a burden.
I believe it's still useful in case one needs to upgrade even an ASDF 3 installation. Particularly if we start work on an ASDF 4 that's not fully compatible.... But perhaps Fare can weigh in on this. best, r
On Tue, Nov 17, 2015 at 6:07 PM, Robert Goldman <rpgoldman@sift.net> wrote:
On 11/17/15 Nov 17 -4:00 PM, Stelian Ionescu wrote:
On Tue, 2015-11-17 at 11:11 -0600, Robert Goldman wrote:
We have had a number of ASDF 3 releases that have mostly been aimed at bug-fixing (although some new features have crept in).
I'd like to declare ASDF 3 feature complete and done, but I don't want to close the door to future bug fix releases as needed, nor do I want to shove incomplete new features out in order to get bug fixes out.
One suggestion I have before doing that is to remove the whole upgrading mechanism. The purpose of it was to allow loading ASDF3 over ASDF 1/2 when the various implementations were only shipping with the latter, but IMO it's now just a burden.
I believe it's still useful in case one needs to upgrade even an ASDF 3 installation. Particularly if we start work on an ASDF 4 that's not fully compatible....
But perhaps Fare can weigh in on this.
I agree that upgrading from asdf 1 or 2 is happily becoming less relevant these days. I'm not sure which parts of the upgrade support exactly can be done away with. Certainly not the parts that declare functions not-inline, etc. Most probably not the parts that deal with package upgrade. But perhaps most of the header, and some of the upgrade magic. Simplifying upgrade would be a good idea for an ASDF 3.2 branch. But on the one hand I'm not sure I want to spend time heavily testing these things on N implementations, as would be required; and on the other hand I suspect the gains will remain minor, though worthwhile. That's would be good exercise for a new ASDF co-maintainer, if someone volunteers to become one. Adding it to the (already large) TODO. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Anyone who goes to a psychiatrist ought to have his head examined. — Samuel Goldwyn
On Wed, Nov 18, 2015 at 12:17 AM, Faré <fahree@gmail.com> wrote:
I agree that upgrading from asdf 1 or 2 is happily becoming less relevant these days.
And still, it looks like this part of the deal could be reduced to just a few lines. See commits 3a9457a, 400c8f5 and 32bf1a28. By being more aggressive on "punting" (i.e. renaming away the ASDF package when upgrading from ASDF 1 or 2, instead of trying to upgrade it in place), I'm not sure what more can be removed without disabling the ability of ASDF to be upgraded *going forward*. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You can always tell who is firmly in power by looking at which ideologies support the disarmament of the population.
On 2015-11-17 18:11 CET, Robert Goldman <rpgoldman@sift.net> wrote:
[...] So I'd like to split ASDF development into stable and testing or something like that.
Does anyone have experience doing that? If so, please post suggestions for process to ASDF-devel.
If we have to support version 3.x and 4.y of a code base, then we create a 'release-3' branch at feature freeze time and keep it after release, so 3.1, 3.2 etc. are created from the tip of 'release-3' where we cherry-pick (mostly bugfix) changes from master. In the meantime, development of version 4 continues in master and when we freeze the features for that version, we create a 'release-4' branch which is then curated until 4.1 can be released. This is a quite transparent model which most developers understand immediately. HTH Kambiz
OK, so here is a concrete proposal for branch names: * "master" for the latest uncontroversial developments, which will become 3.2 * various topic branches to hold controversial or incomplete changes * "release" for the latest release, which will remain 3.1 then become 3.2 * "3.1" for work continued work on ASDF 3.1 after master becomes 3.2 * "release-3.1" for stable releases of ASDF 3.1 after release becomes 3.2 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Evolution competitively selects stable cooperative patterns. On Wed, Nov 18, 2015 at 2:37 AM, Kambiz Darabi <darabi@m-creations.com> wrote:
On 2015-11-17 18:11 CET, Robert Goldman <rpgoldman@sift.net> wrote:
[...] So I'd like to split ASDF development into stable and testing or something like that.
Does anyone have experience doing that? If so, please post suggestions for process to ASDF-devel.
If we have to support version 3.x and 4.y of a code base, then we create a 'release-3' branch at feature freeze time and keep it after release, so 3.1, 3.2 etc. are created from the tip of 'release-3' where we cherry-pick (mostly bugfix) changes from master.
In the meantime, development of version 4 continues in master and when we freeze the features for that version, we create a 'release-4' branch which is then curated until 4.1 can be released.
This is a quite transparent model which most developers understand immediately.
HTH
Kambiz
On 11/18/15 Nov 18 -3:32 PM, Faré wrote:
OK, so here is a concrete proposal for branch names: * "master" for the latest uncontroversial developments, which will become 3.2 * various topic branches to hold controversial or incomplete changes * "release" for the latest release, which will remain 3.1 then become 3.2 * "3.1" for work continued work on ASDF 3.1 after master becomes 3.2 * "release-3.1" for stable releases of ASDF 3.1 after release becomes 3.2
This sounds mostly ok. I kind of prefer "stable" to "3.1" for continued work on the 3.1 series. Rationale: "stable" can't be confused with one of our release tags, the way a numerical branch name could be. I hadn't thought about there being continued stable releases after we move release to 3.2. Hmmmmm...... One more open question: If we move master to be the 3.2 series, then how do we number the interim versions? Previously, 3.1.x.y has been a release candidate for 3.1.x+1, which has been only mildly awkward. But if we start version numbering candidates for the next release this way, then testing with :version really won't work, and there's some danger of version numbering collisions between stable and testing. We could have m.n.0.[1-] be release candidates for m.n, and just always have the final release be m.n.1, which would keep the :VERSION tests working.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Evolution competitively selects stable cooperative patterns.
On Wed, Nov 18, 2015 at 2:37 AM, Kambiz Darabi <darabi@m-creations.com> wrote:
On 2015-11-17 18:11 CET, Robert Goldman <rpgoldman@sift.net> wrote:
[...] So I'd like to split ASDF development into stable and testing or something like that.
Does anyone have experience doing that? If so, please post suggestions for process to ASDF-devel.
If we have to support version 3.x and 4.y of a code base, then we create a 'release-3' branch at feature freeze time and keep it after release, so 3.1, 3.2 etc. are created from the tip of 'release-3' where we cherry-pick (mostly bugfix) changes from master.
In the meantime, development of version 4 continues in master and when we freeze the features for that version, we create a 'release-4' branch which is then curated until 4.1 can be released.
This is a quite transparent model which most developers understand immediately.
HTH
Kambiz
On Wed, Nov 18, 2015 at 5:22 PM, Robert Goldman <rpgoldman@sift.net> wrote:
On 11/18/15 Nov 18 -3:32 PM, Faré wrote:
OK, so here is a concrete proposal for branch names: * "master" for the latest uncontroversial developments, which will become 3.2 * various topic branches to hold controversial or incomplete changes * "release" for the latest release, which will remain 3.1 then become 3.2 * "3.1" for work continued work on ASDF 3.1 after master becomes 3.2 * "release-3.1" for stable releases of ASDF 3.1 after release becomes 3.2
This sounds mostly ok. I kind of prefer "stable" to "3.1" for continued work on the 3.1 series.
Rationale: "stable" can't be confused with one of our release tags, the way a numerical branch name could be.
I hadn't thought about there being continued stable releases after we move release to 3.2. Hmmmmm.....
Yeah, there's an awkward merge or rebase happening when "stable" jumps from 3.1 to 3.2, whereas no such jump happens if old branches have numbered names and are forked off a master that keeps going forward.
One more open question:
If we move master to be the 3.2 series, then how do we number the interim versions? Previously, 3.1.x.y has been a release candidate for 3.1.x+1, which has been only mildly awkward. But if we start version numbering candidates for the next release this way, then testing with :version really won't work, and there's some danger of version numbering collisions between stable and testing.
We could have m.n.0.[1-] be release candidates for m.n, and just always have the final release be m.n.1, which would keep the :VERSION tests working.
That's more or less what we ended doing with 3.1. PS: I removed some of the ancient ASDF 2 compatibility and code to upgrade from it in a fine-grained way — now all implementations "punt" when upgrading from asdf 2, i.e. rename away the old asdf package without trying to reuse its symbols, variables, functions. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It's possible to program a computer in English. It's also possible to make an airplane controlled by reins and spurs. — John McCarthy
On 11/18/15 Nov 18 -8:35 PM, Faré wrote:
Yeah, there's an awkward merge or rebase happening when "stable" jumps from 3.1 to 3.2, whereas no such jump happens if old branches have numbered names and are forked off a master that keeps going forward.
Surely git must have a solution to this problem? There must be a ton of projects that need to have a "stable" and a "development" branch. So this must arise all over the place.... Anyone know?
participants (4)
-
Faré -
Kambiz Darabi -
Robert Goldman -
Stelian Ionescu