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 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.

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 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