[asdf-devel] Re: ASDF 3.0.2.1 released

[Robert Goldman]

Raymond Toy wrote:
>>>>>> "Robert" == Robert Goldman <rpgoldman at sift.info> writes:
> 
>     Robert> Raymond Toy wrote:
>     >> If this is the first release candidate, can you explain the difference
>     >> between this and the 3.0.2 that was released a month or so ago?  I'm a
>     >> bit confused now on the numbering.
> 
>     Robert> I have been assuming that the numbering is:
> 
>     Robert> x.y.z
> 
>     Robert> x = major revision -- I do not expect to preside over one of these!
>     Robert> ASDF 2 was a major clean-up.  ASDF 3 added substantial improvements in
>     Robert> dependency tracking, etc.
> 
>     Robert> y = change to API
> 
>     Robert> z = patch release
> 
>     Robert> This is what is enshrined in the ASDF versioning predicates, so I
>     Robert> figured I would stick with that.
> 
> Thanks.  Previously, I think cmucl only updated on x.y, ignoring z.
> But with asdf 3, I think we updated on x.y.z (3.0.2, in particular).
> 
> I was just wondering now when cmucl should update its copy of asdf.
> And in particular should cmucl take 3.0.2.1?  I have not run into any
> issues with 3.0.2, but I only use a small number of asdf systems.

Implementations should *not* update on tags like 3.0.2.1.

I will *try* to make this clear by not setting the "release" tag to
point to them.  E.g., the current release tag still points to 3.0.2.

Now that ASDF is more and more stable, I hope that implementations will
get happy results updating on x.y.z releases.

To be honest, I haven't thought hard about criteria for x.y releases.
Until now, I have thought of them from the consumer point of view --
bumping the y component was supposed to indicate a change in API.

If we should be so lucky as to get through a long period without such a
change (e.g., six months), then maybe we should rebrand the latest 3.0.x
at that time as 3.1 just to encourage implementations to upgrade.

It's a thought.

best,
R