Raymond Toy wrote:
"Robert" == Robert Goldman <rpgoldman@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