[asdf-devel] ASDF 3.0.2.1 released
ASDF 3.0.2.1 is the first candidate release for ASDF, containing several bug fixes. If you can, please grab this ASDF release and test it with your systems, and by running make test or make test-all Please report any bugs you find to the ASDF project on launchpad.net We'd like this to pave the way for the best, most solid ASDF release ever! Best, R
"Robert" == Robert Goldman <rpgoldman@sift.info> writes:
Robert> ASDF 3.0.2.1 is the first candidate release for ASDF, containing several Robert> bug fixes. 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> If you can, please grab this ASDF release and test it with your systems, Robert> and by running Robert> make test I ran this with the latest snapshot of cmucl. All tests pass, as expected. Ray
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.
I have been assuming that the numbering is: x.y.z x = major revision -- I do not expect to preside over one of these! ASDF 2 was a major clean-up. ASDF 3 added substantial improvements in dependency tracking, etc. y = change to API z = patch release This is what is enshrined in the ASDF versioning predicates, so I figured I would stick with that. Faré has always put a revision tag on everything, I suppose to make it easier to identify where bugs appear and don't, etc. So I have been sticking with this standard practice by adding that extra .1. I hope that helps. Let me know if further clarification is needed. Glad to hear things are working with CMUCL. Which platform(s) did you test? Best, r
"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. Robert> Glad to hear things are working with CMUCL. Which platform(s) did you test? I ran it on OSX and Linux. Everything was fine. :-) Ray
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
"Robert" == Robert Goldman <rpgoldman@sift.info> writes:
Robert> 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. Robert> Implementations should *not* update on tags like 3.0.2.1. Robert> I will *try* to make this clear by not setting the "release" tag to Robert> point to them. E.g., the current release tag still points to 3.0.2. Thanks for clarifying this. I'll refrain from updating unless there's a "release". BTW, what is this "release" tag? Is it in git? If not, that would be nice to have, because right now, I just see a bunch of numerical tags corresponding to the version (and various upstream and debian tags). Ray
Raymond Toy wrote:
"Robert" == Robert Goldman <rpgoldman@sift.info> writes:
Robert> 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.
Robert> Implementations should *not* update on tags like 3.0.2.1.
Robert> I will *try* to make this clear by not setting the "release" tag to Robert> point to them. E.g., the current release tag still points to 3.0.2.
Thanks for clarifying this. I'll refrain from updating unless there's a "release". BTW, what is this "release" tag? Is it in git? If not, that would be nice to have, because right now, I just see a bunch of numerical tags corresponding to the version (and various upstream and debian tags).
Ray
Yes, there's a release tag. You can see it in the gitweb: http://common-lisp.net/gitweb?p=projects/asdf/asdf.git
"Robert" == Robert Goldman <rpgoldman@sift.info> writes:
Robert> Raymond Toy wrote: >>>>>>> "Robert" == Robert Goldman <rpgoldman@sift.info> writes: >> Robert> 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. >> Robert> Implementations should *not* update on tags like 3.0.2.1. >> Robert> I will *try* to make this clear by not setting the "release" tag to Robert> point to them. E.g., the current release tag still points to 3.0.2. >> >> Thanks for clarifying this. I'll refrain from updating unless there's >> a "release". BTW, what is this "release" tag? Is it in git? If not, >> that would be nice to have, because right now, I just see a bunch of >> numerical tags corresponding to the version (and various upstream and >> debian tags). >> >> Ray >> >> Robert> Yes, there's a release tag. You can see it in the gitweb: Robert> http://common-lisp.net/gitweb?p=projects/asdf/asdf.git Oh, you mean release branch? I was looking at the output of git tag and didn't see anything. :-) (I also didn't have a local release branch, but I do now.) Ray
Yes, I believe the intent is to have the release branch always point to the latest released version. Sent from my iPad On Jul 31, 2013, at 17:14, Raymond Toy <toy.raymond@gmail.com> wrote:
"Robert" == Robert Goldman <rpgoldman@sift.info> writes:
Robert> Raymond Toy wrote:
>> "Robert" == Robert Goldman <rpgoldman@sift.info> writes: Robert> 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. Robert> Implementations should *not* update on tags like 3.0.2.1. Robert> I will *try* to make this clear by not setting the "release" tag to Robert> point to them. E.g., the current release tag still points to 3.0.2.
Thanks for clarifying this. I'll refrain from updating unless there's a "release". BTW, what is this "release" tag? Is it in git? If not, that would be nice to have, because right now, I just see a bunch of numerical tags corresponding to the version (and various upstream and debian tags).
Ray
Robert> Yes, there's a release tag. You can see it in the gitweb:
Robert> http://common-lisp.net/gitweb?p=projects/asdf/asdf.git
Oh, you mean release branch? I was looking at the output of git tag and didn't see anything. :-) (I also didn't have a local release branch, but I do now.)
Ray
On Wed, Jul 31, 2013 at 1:38 PM, Raymond Toy <toy.raymond@gmail.com> wrote:
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).
Yes, I changed the numbering with ASDF 3, so that it be possible to signal significant changes that aren't compatibility breakers: the first number is a major version, and bumping it means that some notable incompatible changes were made, as was the case between ASDF 2 and ASDF 3. The second number is a minor version number; it now allows the maintainer to signal some significant milestone that did not notably break compatibility. The third number (previously, second) is the release number; it is bumped at every release. The fourth number (previously, third), when present, is changed at every revision, and indicates a non-released revision. A fifth number (previously, fourth), when present, is the recommended way to indicate a local patch that was not committed upstream. Therefore, 2.26 was the 27th release of ASDF 2 (the English language has an off by one error, remember?), whereas 3.0.2 was the 3rd release of ASDF 3.0. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Human Action is based on plans, rules, contracts; praxeology is the science of the underlying concepts and their necessary consequences.
On Wed, Jul 31, 2013 at 12:53 PM, Robert Goldman <rpgoldman@sift.info> wrote:
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.
I have been assuming that the numbering is:
x.y.z
x = major revision -- I do not expect to preside over one of these! ASDF 2 was a major clean-up. ASDF 3 added substantial improvements in dependency tracking, etc.
y = change to API
z = patch release
This is what is enshrined in the ASDF versioning predicates, so I figured I would stick with that.
Yes, that's about what it is. There's a comment around one of the occurrences of the version string, explaining the version scheme.
Faré has always put a revision tag on everything, I suppose to make it easier to identify where bugs appear and don't, etc. So I have been sticking with this standard practice by adding that extra .1.
Actually, (a) I've only systematically put a git tag but on released versions and a few notable other versions; but (b) I've tried to bump the version number any time there was a change in asdf.lisp, so the number can always be used to precisely identify the code in a bug report. That's why (c) I've been using an extra digit such as this .1 in unreleased versions, to distinguish any two versions pushed to master. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It should be a grammatical if not legal offense to ascribe thoughts, opinions and decisions to "we" without a signed power of attorney.
participants (4)
-
Faré -
Raymond Toy -
Robert Goldman -
Robert P. Goldman