[asdf-devel] versioning [was Re: asdf verbosity]

[Faré]

On 27 April 2011 12:57,  <dherring at tentpost.com> wrote:
> These are probably good things, but as Zach mentioned, recently ASDF has
> started dragging users through internal development.  Its a gripe I have
> about Slime and some other key libraries, so you are in good company, but
> I cannot follow "the bleeding edge" as a matter of habit.
>
Uh - I've been trying my darned best to make "release" versions stable,
e.g. 2.010, 2.011, 2.012, 2.013, 2.014. I may not have been as successful
at it as I'd like, but so far as I can tell, all the complaints (which
are justified and most welcome) had to do with non-release versions, e.g.
2.014.8, etc.

That's not to say that I couldn't be doing better, but yes,
1) trying trunk will give you regressions like that.
2) if you're a power user like Zach, you unhappily have to test with trunk
 to weed out the problems, or the bugs will make it into a release.
3) Recent bugs and feature requests have prompted some refactorings,
 and along the way I've made changes that didn't make everyone happy.
4) So far as I can tell, we're still on a good path to making the next
 stable release satisfactory to everyone.

If this is not your perception, then maybe we can have a discussion
on the details of what went wrong and how to avoid the same in the future.

> Releases broadly fall into three social categories.  Micro releases only
> fix internal bugs and have no other user visibility.  Minor releases
> modify behavior but should be compatible with previous releases, still
> requiring no user interaction.  Major releases require the user to
> understand what's changed and modify code or config files.  Major releases
> need to happen slowly to minimize end-user churn, ensure proper vetting,
> etc.  Major releases often come with nice ChangeLog entries summarizing
> what to expect.
>
Agreed.

> I think many recent ASDF changes have been good, but they are falling into
> the major release category.  They can't be going into monthly Quicklisp or
> SBCL updates or (your favorite distribution channel here).
>
Do you call 2.014 vs 2.011 "major"?
Certainly, I haven't been pushing for development versions like 2.014.12
to be put into either Quicklisp or SBCL. That said, bugfixes or features
required for Quicklisp may have pushed Xach to upgrade anyway. And he is
in the unhappy situation of being my first line tester for many systems.

> This is where "trunk" and "release/stable branches" work fairly well.
> Tagging trunk is not equivalent.  If a project does not have the resources
> to maintain a separate release branch, then they should simply tag major
> releases at a slower rate.
>
In my terminology, I count 2.000 as a major release, 2.014 as a minor release,
and 2.014.13 as a development version. I've done a major release once,
last year. I've had 14 minor releases since, and hundreds of develop versions.
I'm tagging minor releases about once a month, and pushing for them to be
adopted by various vendors. If any of this is out of synch with your
expectations, please be more specific in your criticism.

> People who want the latest can always look directly at trunk.  Discussion
> can still be happening on list.
>
That's also my understanding.

> Its just that the end user should have to be involved.
I don't understand what THAT means.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
You can tell whether a man is clever by his answers.
You can tell whether a man is wise by his questions. — Naguib Mahfouz