The next item to merge is Alberto's !192. This is new functionality, rather than a bug fix, so I am considering adding a `main` branch, retiring `master`, and moving most activity there, with an eye to getting the first 3.4 release underway. That would permit me to start merging a number of things that add new capabilities that don't seem like a patch version.
Alternatively, we could just keep `master`, but it seems like that is becoming old standard practice, so changing to `main` would comply with the new de facto standard established by GitHub.
Then, if we want to back patch, we can create a `stable` branch and cherry-pick onto that (using `maint` would create too much potential for confusion).
Thoughts?
Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner.
Another 3.3 release might be in order to get !189 out (although maybe it's not that important; I'm honestly surprised by how few complaints I've seen about it).
And if there's another 3.3 release, I'd like to nominate !194 for merging beforehand. !195 is also a bug fix, but the bug has existed for almost as long as the feature has been around. So perhaps delaying it for 3.4 is more prudent.
On 11/17/21 9:14 AM, Robert Goldman wrote:
Then, if we want to back patch, we can create a |stable| branch and cherry-pick onto that (using |maint| would create too much potential for confusion).
I'd suggest something like 3-3-stable instead (or really anything that gets the 3.3 in there). The branch can be deleted when 3.4 is released so we're not supporting more than one release at a time. I still think having a "stable" branch whose history changes isn't a great idea.
-Eric
Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner.
Adding fine-grained version constraints would be a big mistake. Where they've already been implemented (Ruby, Python, Haskell), they've invariably lead to authors selecting overly restrictive contraints because there's no automatic way to determing the minimum version required from dependencies. In turn, that makes even installing a package a nightmare because it often leads to unsatisfiable dependencies and having to (manually) backtrack until one can find a combination of compatible packages. The distribution model that Quicklisp has, by snapshotting the "world" once a month and ensuring that they all compile is much better so let's keep it that way.
If you think I'm exagerating, ask people that are familiar with the process of having to update a Ruby webapp (or a Jekyll blog with many plugins), or even a Python virtualenv-based server. Especially the Ruby community went down this rabbit hole to far that it's no wonder they were the first to adopt Docker back in the days: instead of subjecting users to the dance of "let's see if I can even get this to install" they ended up shipping a whole container as a workaround.
On 17 Nov 2021, at 10:35, Stelian Ionescu wrote:
Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner.
Adding fine-grained version constraints would be a big mistake. Where they've already been implemented (Ruby, Python, Haskell), they've invariably lead to authors selecting overly restrictive contraints because there's no automatic way to determing the minimum version required from dependencies. In turn, that makes even installing a package a nightmare because it often leads to unsatisfiable dependencies and having to (manually) backtrack until one can find a combination of compatible packages. The distribution model that Quicklisp has, by snapshotting the "world" once a month and ensuring that they all compile is much better so let's keep it that way.
If you think I'm exagerating, ask people that are familiar with the process of having to update a Ruby webapp (or a Jekyll blog with many plugins), or even a Python virtualenv-based server. Especially the Ruby community went down this rabbit hole to far that it's no wonder they were the first to adopt Docker back in the days: instead of subjecting users to the dance of "let's see if I can even get this to install" they ended up shipping a whole container as a workaround.
I have mixed feelings about this:
1. I agree that the situation in Python is a hot mess. I'm not sure how much this is due to versioning messes as opposed to the excess specificity that one gets from `pip freeze`, and another confound is the multi-headed horror that is Python package construction and management.
2. I *desperately* want to add version upper bounds. There is a real problem of having someone change a library under one's system, and *pace* Faré, sometimes one does not have the resources to handle updates to every library in one's build chain. It's always better for the poor user to see an error message saying that something won't work because of a library update, instead of seeing some kind of horrible mess with no clue where to look.
3. I am not that worried that we will end up in the kind of mess that concerns you: right now there are an enormous number of Lisp libraries that don't even have version metadata _at all_ . So if people want to use expressive versioning in a sub-region of the lisp development ecosystem, that is unlikely to cause the problems you see, and might help *some* of us manage our dependencies.
Cheers, R
On 17 Nov 2021, at 10:35, Stelian Ionescu wrote:
Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner.
Adding fine-grained version constraints would be a big mistake. Where they've already been implemented (Ruby, Python, Haskell), they've invariably lead to authors selecting overly restrictive contraints because there's no automatic way to determing the minimum version required from dependencies. In turn, that makes even installing a package a nightmare because it often leads to unsatisfiable dependencies and having to (manually) backtrack until one can find a combination of compatible packages. The distribution model that Quicklisp has, by snapshotting the "world" once a month and ensuring that they all compile is much better so let's keep it that way.
If you think I'm exagerating, ask people that are familiar with the process of having to update a Ruby webapp (or a Jekyll blog with many plugins), or even a Python virtualenv-based server. Especially the Ruby community went down this rabbit hole to far that it's no wonder they were the first to adopt Docker back in the days: instead of subjecting users to the dance of "let's see if I can even get this to install" they ended up shipping a whole container as a workaround.
I have mixed feelings about this:
- I agree that the situation in Python is a hot mess. I'm not sure how much this is due to versioning messes as opposed to the excess specificity that one gets from `pip freeze`, and another confound is the multi-headed horror that is Python package construction and management.
Dependency freezing is yet another symptom of the problem: because the dependency hell makes it difficult to find a mutually compatible version set, authors make their own life easy by freezing deps, but that works poorly with the rest of the ecosystem. The last time the problem of incompatible versions bit me I was trying to update my blog based on Octopress+Jekyll, and found that the latest release of each of the packages that I required - including plugins - couldn't be installed together. I had to manually backtrack by tweaking the versions (since rubygems didn't do that automatically), and it took me a few hours to converge on a working install. The year after I switched to Hugo.
- I *desperately* want to add version upper bounds. There is a real problem of having someone change a library under one's system, and *pace* Faré, sometimes one does not have the resources to handle updates to every library in one's build chain.
It's part of the social contract of open source that you get things for free but you need to stay up-to-date with your dependencies. If a library changes too often, it's a social problem and shouldn't be addressed with technical means: talk to the author and ask to keep backwards-compatibility for a while longer or remove/replace the dependency. I cannot stress enough how much better the Quicklisp monthly distribution model is compared to what I see anywhere else. Once you open this Pandora's box there will be no going back (are you open to removing the feature from ASDF if it goes bad ?).
It's always better for the poor user to see an error message saying that something won't work because of a library update, instead of seeing some kind of horrible mess with no clue where to look.
- I am not that worried that we will end up in the kind of mess that concerns you: right now there are an enormous number of Lisp libraries that don't even have version metadata *at all* . So if people want to use expressive versioning in a sub-region of the lisp development ecosystem, that is unlikely to cause the problems you see, and might help *some* of us manage our dependencies.
I am worried because once you make something easy, people will be tempted to use that feature. Authors aren't currently adding metadata because it's purely decorative and there's no real gain in maintaining that.
-- Stelian Ionescu
On 17 Nov 2021, at 11:08, Stelian Ionescu wrote:
- I *desperately* want to add version upper bounds. There is a real
problem of having someone change a library under one's system, and *pace* Faré, sometimes one does not have the resources to handle updates to every library in one's build chain.
It's part of the social contract of open source that you get things for free but you need to stay up-to-date with your dependencies.
That simply does not work for everyone, *definitely* including me. My company can't afford to pay me to keep every piece of software lying around updated with all of its dependencies. When a contract is done, I often can no longer maintain related software. Similarly, I use a lot of software written at universities as part of some research project that will eventually end. Other examples abound. There's a *lot* of software out there that could be useful, but that is not useful enough to the original author that they are going to maintain it *ad infinitum*.
In such cases it's better that if we pull this stuff out of mothballs: (1) we don't have to flail around trying to guess why it doesn't work any more and (2) we can find an old working configuration.
In the best of all possible worlds, everything would always be up-to-date, but that is not the world we live in -- or at least not the one that I live in.
- I am not that worried that we will end up in the kind of mess
that concerns you: right now there are an enormous number of Lisp libraries that don't even have version metadata *at all* . So if people want to use expressive versioning in a sub-region of the lisp development ecosystem, that is unlikely to cause the problems you see, and might help *some* of us manage our dependencies.
I am worried because once you make something easy, people will be tempted to use that feature. Authors aren't currently adding metadata because it's purely decorative and there's no real gain in maintaining that.
On the contrary, *minimum* version constraints already exist. So it's not true that metadata is purely decorative. It's because people are slobs, or are not aware that the metadata are available.
--
The argument here is the same argument as Faré has made: all software should always be maintained and kept-up-to-date. But Faré is a programming superhero. I'm a mere mortal, but I *am* the ASDF maintainer, and at the end of the day, I have decided that version constraints like `(:version "my-unstable-library" < 3)` or something like that *will* go in to ASDF.
The worst that will happen is that someone will put in an overly-restrictive version constraint. Given the state of the CL software ecosystem vs., e.g., Python, I think it's quite unlikely that there will be a lot of overly-tight restrictions out there. And the ability to have upper bounds meets an actual need that is under-served.
On 17 Nov 2021, at 11:08, Stelian Ionescu wrote:
- I *desperately* want to add version upper bounds. There is a real problem of having someone change a library under one's system, and *pace* Faré, sometimes one does not have the resources to handle updates to every library in one's build chain.
It's part of the social contract of open source that you get things for free but you need to stay up-to-date with your dependencies.
That simply does not work for everyone, *definitely* including me. My company can't afford to pay me to keep every piece of software lying around updated with all of its dependencies. When a contract is done, I often can no longer maintain related software. Similarly, I use a lot of software written at universities as part of some research project that will eventually end. Other examples abound. There's a *lot* of software out there that could be useful, but that is not useful enough to the original author that they are going to maintain it *ad infinitum*.
In such cases it's better that if we pull this stuff out of mothballs: (1) we don't have to flail around trying to guess why it doesn't work any more and (2) we can find an old working configuration.
To guarantee an old working configuration you can simply point to the version of the Quicklisp distribution that it was last tested with. We should make it easy to specify that as metadata, and it would be much more useful than version constraints because ASDF is not blocking compilation (after all, even old software might very well work with newer version of the dependencies).
In the best of all possible worlds, everything would always be up-to-date, but that is not the world we live in -- or at least not the one that I live in.
- I am not that worried that we will end up in the kind of mess that concerns you: right now there are an enormous number of Lisp libraries that don't even have version metadata *at all* . So if people want to use expressive versioning in a sub-region of the lisp development ecosystem, that is unlikely to cause the problems you see, and might help *some* of us manage our dependencies.
I am worried because once you make something easy, people will be tempted to use that feature. Authors aren't currently adding metadata because it's purely decorative and there's no real gain in maintaining that.
On the contrary, *minimum* version constraints already exist. So it's not true that metadata is purely decorative. It's because people are slobs, or are not aware that the metadata are available.
--
The argument here is the same argument as Faré has made: all software should always be maintained and kept-up-to-date. But Faré is a programming superhero. I'm a mere mortal, but I *am* the ASDF maintainer, and at the end of the day, I have decided that version constraints like `(:version "my-unstable-library" < 3)` or something like that *will* go in to ASDF.
The worst that will happen is that someone will put in an overly-restrictive version constraint. Given the state of the CL software ecosystem vs., e.g., Python, I think it's quite unlikely that there will be a lot of overly-tight restrictions out there. And the ability to have upper bounds meets an actual need that is under-served.
-- Stelian Ionescu
On 17 Nov 2021, at 12:26, Stelian Ionescu wrote:
To guarantee an old working configuration you can simply point to the version of the Quicklisp distribution that it was last tested with. We should make it easy to specify that as metadata, and it would be much more useful than version constraints because ASDF is not blocking compilation (after all, even old software might very well work with newer version of the dependencies).
This would be to assume that ASDF is only used in conjunction with Quicklisp, which is not the case.
On 17 Nov 2021, at 12:26, Stelian Ionescu wrote:
To guarantee an old working configuration you can simply point to the version of the Quicklisp distribution that it was last tested with. We should make it easy to specify that as metadata, and it would be much more useful than version constraints because ASDF is not blocking compilation (after all, even old software might very well work with newer version of the dependencies).
This would be to assume that ASDF is only used in conjunction with Quicklisp, which is not the case.
You don't have to use the Quicklisp client to load dependencies, just to fetch them (as a package manager). And for that, I think it should be always used this way.
On 17 Nov 2021, at 12:32, Stelian Ionescu wrote:
You don't have to use the Quicklisp client to load dependencies, just to fetch them (as a package manager). And for that, I think it should be always used this way.
That only works if you are using the QL libraries unchanged. If you need to patch or extend them, you need to set up a repo and handle things yourself.
I was doing a lot of work on Allegro back in the day, and I found that many of the libraries I encountered only worked properly on SBCL.
At that point I started always working from source repos, rather than initially getting from QL and then having to backtrack to source repo when the library broke.
So I am definitely not going to make ASDF just the build system for Quicklisp!
I am *always* willing to cooperate with Xach or anyone else to make ASDF work smoothly with QL, but ASDF will never be just a QL module.
On 17 Nov 2021, at 12:32, Stelian Ionescu wrote:
You don't have to use the Quicklisp client to load dependencies, just to fetch them (as a package manager). And for that, I think it should be always used this way.
That only works if you are using the QL libraries unchanged. If you need to patch or extend them, you need to set up a repo and handle things yourself.
This is definitely not true. You can configure ASDF pretty easily in such a way that you have a directory of local dependencies which override the ones in Quicklisp. I have lots of locally patched libraries and never had any problem with that.
-- Stelian Ionescu
On 17 Nov 2021, at 14:03, Stelian Ionescu wrote:
On 17 Nov 2021, at 12:32, Stelian Ionescu wrote:
You don't have to use the Quicklisp client to load dependencies, just to fetch them (as a package manager). And for that, I think it should be always used this way.
That only works if you are using the QL libraries unchanged. If you need to patch or extend them, you need to set up a repo and handle things yourself.
This is definitely not true. You can configure ASDF pretty easily in such a way that you have a directory of local dependencies which override the ones in Quicklisp. I have lots of locally patched libraries and never had any problem with that.
What I mean is that Quicklisp doesn't handle this -- you fall back on ASDF without QL.
Specifically, if the library needs patching, you need to go out and find it. AFAIK QL won't help you find the source and check it out, for example.
I found myself doing that enough that I just went directly to checking out the source, and skipping QL altogether.
On 17 Nov 2021, at 14:03, Stelian Ionescu wrote:
On 17 Nov 2021, at 12:32, Stelian Ionescu wrote:
You don't have to use the Quicklisp client to load dependencies, just to fetch them (as a package manager). And for that, I think it should be always used this way.
That only works if you are using the QL libraries unchanged. If you need to patch or extend them, you need to set up a repo and handle things yourself.
This is definitely not true. You can configure ASDF pretty easily in such a way that you have a directory of local dependencies which override the ones in Quicklisp. I have lots of locally patched libraries and never had any problem with that.
What I mean is that Quicklisp doesn't handle this -- you fall back on ASDF without QL. Specifically, if the library needs patching, you need to go out and find it. AFAIK QL won't help you find the source and check it out, for example.
Sure, if you need a fork that is outside Quicklisp you should fetch it yourself.
Stelian Ionescu wrote:
Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner.
Adding fine-grained version constraints would be a big mistake.
I do not have the time to check this thoroughly right now, but I recall having suggested that ASDF shouldn't impose any constraints on version "numbers", but rather defer version comparison to libraries when they use a version numbering scheme that ASDF doesn't understand. This can be done by providing generic functions like version-> etc., and letting people provide methods on them.
There may even be an issue and a patch lurking around somewhere. Again, sorry for being fuzzy, this is just from the top of my head.
`version-satisfies` is *already* a generic function. We will add some more capabilities to the built-in version in ASDF 3.4, but library authors will continue to be able to implement their own extensions.
On 17 Nov 2021, at 11:24, Didier Verna wrote:
Stelian Ionescu wrote:
Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner.
Adding fine-grained version constraints would be a big mistake.
I do not have the time to check this thoroughly right now, but I recall having suggested that ASDF shouldn't impose any constraints on version "numbers", but rather defer version comparison to libraries when they use a version numbering scheme that ASDF doesn't understand. This can be done by providing generic functions like version-> etc., and letting people provide methods on them.
There may even be an issue and a patch lurking around somewhere. Again, sorry for being fuzzy, this is just from the top of my head.
-- Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
On 11/17/21 12:24 PM, Didier Verna wrote:
Stelian Ionescu wrote:
Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner.
Adding fine-grained version constraints would be a big mistake.
I do not have the time to check this thoroughly right now, but I recall having suggested that ASDF shouldn't impose any constraints on version "numbers", but rather defer version comparison to libraries when they use a version numbering scheme that ASDF doesn't understand. This can be done by providing generic functions like version-> etc., and letting people provide methods on them. > There may even be an issue and a patch lurking around somewhere. Again, sorry for being fuzzy, this is just from the top of my head.
Hi Didier,
I started from your patch on this, with the intention of allowing arbitrary version strings (so long as the protocol is fully implemented).
I'd like to also extend ASDF's default to be more than just dot-separated numbers. The leading contenders at the moment are "semver style" where prerelease info is separated by a #-, "build" metadata separated by a #+, and no post-release info (NOTE: I am just talking about version string grammar here, *not* about compatibility constraints!) and something like PEP 440 https://www.python.org/dev/peps/pep-0440/, which as I recall is very similar to the style you prefer.
I have a preference toward the semver style because it's less restrictive and there's no notion of "canonical form" (unlike PEP 440), so it's easier to implement.
-Eric
On 17 Nov 2021, at 12:36, Eric Timmons wrote:
On 11/17/21 12:24 PM, Didier Verna wrote:
Stelian Ionescu wrote:
Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner.
Adding fine-grained version constraints would be a big mistake.
I do not have the time to check this thoroughly right now, but I recall having suggested that ASDF shouldn't impose any constraints on version "numbers", but rather defer version comparison to libraries when they use a version numbering scheme that ASDF doesn't understand. This can be done by providing generic functions like version-> etc., and letting people provide methods on them. > There may even be an issue and a patch lurking around somewhere. Again, sorry for being fuzzy, this is just from the top of my head.
Hi Didier,
I started from your patch on this, with the intention of allowing arbitrary version strings (so long as the protocol is fully implemented).
I'd like to also extend ASDF's default to be more than just dot-separated numbers. The leading contenders at the moment are "semver style" where prerelease info is separated by a #-, "build" metadata separated by a #+, and no post-release info (NOTE: I am just talking about version string grammar here, *not* about compatibility constraints!) and something like PEP 440 https://www.python.org/dev/peps/pep-0440/, which as I recall is very similar to the style you prefer.
I have a preference toward the semver style because it's less restrictive and there's no notion of "canonical form" (unlike PEP 440), so it's easier to implement.
-Eric
I favor something like this because it would be nice to have prerelease versions of ASDF that perform version checks properly.
What I mean is, if we are going to add a feature in version 3.4, right now that would be in a prerelease version with a version number of something like 3.3.5.22
It would be a lot better for realistic testing if we could instead use 3.4.0-alpha1 or 3.4.0-1 *and* have ASDF know that 3.4.0-1 comes *before* 3.4.0, not after.
On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman rpgoldman@sift.info wrote:
I favor something like this because it would be nice to have prerelease versions of ASDF that perform version checks properly.
What I mean is, if we are going to add a feature in version 3.4, right now that would be in a prerelease version with a version number of something like 3.3.5.22
It would be a lot better for realistic testing if we could instead use 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that 3.4.0-1 comes before 3.4.0, not after.
Hi Robert, hi everyone. I haven't been following closely, but while you are working out details, let me just mention that I recommend against version numbers that require special interpretation to discover their ordering, e.g. 3.4.0-1 < 3.4.0.
Mostly I'm just thinking that somebody's not going to get the memo (it's usually me).
For what it's worth, and all the best.
Robert.
On Wed, 17 Nov 2021, Robert Dodier wrote:
On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman rpgoldman@sift.info wrote:
I favor something like this because it would be nice to have prerelease versions of ASDF that perform version checks properly.
What I mean is, if we are going to add a feature in version 3.4, right now that would be in a prerelease version with a version number of something like 3.3.5.22
It would be a lot better for realistic testing if we could instead use 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that 3.4.0-1 comes before 3.4.0, not after.
Hi Robert, hi everyone. I haven't been following closely, but while you are working out details, let me just mention that I recommend against version numbers that require special interpretation to discover their ordering, e.g. 3.4.0-1 < 3.4.0.
Mostly I'm just thinking that somebody's not going to get the memo (it's usually me).
Yeah, I find that one odd as well.
-andreas
On 17 Nov 2021, at 13:31, Robert Dodier wrote:
On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman rpgoldman@sift.info wrote:
I favor something like this because it would be nice to have prerelease versions of ASDF that perform version checks properly.
What I mean is, if we are going to add a feature in version 3.4, right now that would be in a prerelease version with a version number of something like 3.3.5.22
It would be a lot better for realistic testing if we could instead use 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that 3.4.0-1 comes before 3.4.0, not after.
Hi Robert, hi everyone. I haven't been following closely, but while you are working out details, let me just mention that I recommend against version numbers that require special interpretation to discover their ordering, e.g. 3.4.0-1 < 3.4.0.
Mostly I'm just thinking that somebody's not going to get the memo (it's usually me).
For what it's worth, and all the best.
I guess that would be an argument for using something more obvious than `-`, like the string `alpha` so `3.4.0-alpha1` or `3.4.0alpha1` instead of `3.4.0-1` since there the meaning should be relatively obvious.
My feeling is that if a user misinterprets `3.4.0-1`, then shame on me. But if a user misinterprets `3.4.0alpha1` then shame on them.
I'm not sure how that would align with semver...
From semver.org:
Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
Regards,
Erik
On Wed, Nov 17, 2021 at 8:38 PM Robert Goldman rpgoldman@sift.info wrote:
On 17 Nov 2021, at 13:31, Robert Dodier wrote:
On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman rpgoldman@sift.info wrote:
I favor something like this because it would be nice to have prerelease versions of ASDF that perform version checks properly.
What I mean is, if we are going to add a feature in version 3.4, right now that would be in a prerelease version with a version number of something like 3.3.5.22
It would be a lot better for realistic testing if we could instead use 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that 3.4.0-1 comes before 3.4.0, not after.
Hi Robert, hi everyone. I haven't been following closely, but while you are working out details, let me just mention that I recommend against version numbers that require special interpretation to discover their ordering, e.g. 3.4.0-1 < 3.4.0.
Mostly I'm just thinking that somebody's not going to get the memo (it's usually me).
For what it's worth, and all the best.
I guess that would be an argument for using something more obvious than -, like the string alpha so 3.4.0-alpha1 or 3.4.0alpha1 instead of 3.4.0-1 since there the meaning should be relatively obvious.
My feeling is that if a user misinterprets 3.4.0-1, then shame on me. But if a user misinterprets 3.4.0alpha1 then shame on them.
I'm not sure how that would align with semver...
On 11/17/21 2:38 PM, Robert Goldman wrote:
On 17 Nov 2021, at 13:31, Robert Dodier wrote:
On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman rpgoldman@sift.info <mailto:rpgoldman@sift.info> wrote: I favor something like this because it would be nice to have prerelease versions of ASDF that perform version checks properly. What I mean is, if we are going to add a feature in version 3.4, right now that would be in a prerelease version with a version number of something like 3.3.5.22 It would be a lot better for realistic testing if we could instead use 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that 3.4.0-1 comes before 3.4.0, not after. Hi Robert, hi everyone. I haven't been following closely, but while you are working out details, let me just mention that I recommend against version numbers that require special interpretation to discover their ordering, e.g. 3.4.0-1 < 3.4.0. Mostly I'm just thinking that somebody's not going to get the memo (it's usually me). For what it's worth, and all the best.I guess that would be an argument for using something more obvious than |-|, like the string |alpha| so |3.4.0-alpha1| or |3.4.0alpha1| instead of |3.4.0-1| since there the meaning should be relatively obvious.
My feeling is that if a user misinterprets |3.4.0-1|, then shame on me. But if a user misinterprets |3.4.0alpha1| then shame on them.
I'm not sure how that would align with semver...
Erik already sent out some examples of ordering with semver. But it is worth noting that 3.4.0-1 *is* valid semver and the ordering would be 3.4.0-1 < 3.4.0-alpha
So to prevent misinterpretation of 3.4.0-1, ASDF could either promise to always use something like alpha/beta/etc, use something else like PEP440 (I believe that grammar always requires an alphabetic character for pre-releases), or bake its own grammar.
One thing that's nice about the semver grammar is its flexibility. I have some scripts that can generate a version string from a git repo that lets you easily order versions based on things like when they branched off the default branch. But if we want ASDF to disallow things like 3.4.0-1, I'm happy to build my own system that uses the new API to allow the use of semver strings.
Another option is to choose something compatible with Debian's version strings. I'm having a little trouble grokking it at the moment, but it seems to be even more freeform than semver and adds an optional epoch prefix.
-Eric
On 17 Nov 2021, at 15:12, Eric Timmons wrote:
On 11/17/21 2:38 PM, Robert Goldman wrote:
On 17 Nov 2021, at 13:31, Robert Dodier wrote:
On Wed, Nov 17, 2021 at 10:45 AM Robert Goldmanrpgoldman@sift.info mailto:rpgoldman@sift.info wrote:
I favor something like this because it would be nice to have prerelease versions of ASDF that perform version checksproperly.
What I mean is, if we are going to add a feature in version3.4, right now that would be in a prerelease version with a version number of something like 3.3.5.22
It would be a lot better for realistic testing if we could instead use 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that 3.4.0-1 comes before 3.4.0, not after. Hi Robert, hi everyone. I haven't been following closely, butwhile you are working out details, let me just mention that I recommend against version numbers that require special interpretation to discover their ordering, e.g. 3.4.0-1 < 3.4.0.
Mostly I'm just thinking that somebody's not going to get thememo (it's usually me).
For what it's worth, and all the best.I guess that would be an argument for using something more obvious than |-|, like the string |alpha| so |3.4.0-alpha1| or |3.4.0alpha1| instead of |3.4.0-1| since there the meaning should be relatively obvious.
My feeling is that if a user misinterprets |3.4.0-1|, then shame on me. But if a user misinterprets |3.4.0alpha1| then shame on them.
I'm not sure how that would align with semver...
Erik already sent out some examples of ordering with semver. But it is worth noting that 3.4.0-1 *is* valid semver and the ordering would be 3.4.0-1 < 3.4.0-alpha
So to prevent misinterpretation of 3.4.0-1, ASDF could either promise to always use something like alpha/beta/etc, use something else like PEP440 (I believe that grammar always requires an alphabetic character for pre-releases), or bake its own grammar.
One thing that's nice about the semver grammar is its flexibility. I have some scripts that can generate a version string from a git repo that lets you easily order versions based on things like when they branched off the default branch. But if we want ASDF to disallow things like 3.4.0-1, I'm happy to build my own system that uses the new API to allow the use of semver strings.
Another option is to choose something compatible with Debian's version strings. I'm having a little trouble grokking it at the moment, but it seems to be even more freeform than semver and adds an optional epoch prefix.
What might be nice would be to support a *subset* of semver by default -- not allowing the numerical prerelease flagged with `-` -- but do so in a way that is extensible.
Here's my rationale: I would like to provide a relatively simple semantic versioning that is also compatible with automatically detecting and rejecting ill-formed version strings.
So, for example, we could (by default!) split the version strings by `#.` and `#-` and *reject* any string bounded by `#.` that is not numerical.
We could demand, again by default, that the substring following the `#-` be of some constrained form: e.g., Greek letter name followed by optional numeral. For that matter, we could just say "hey, alpha and beta are enough" and reject anything but those two. That would be a nice alternative to having a big table of Greek letter names in ASDF!
Finally, for those who want to really go for it, we could add a `:version-scheme` keyword to `defsystem`, which would initially default to `:unconstrained`, but then through the standard process of warning and then erroring, migrate to `:standard` (or perhaps `:asdf`) as the default, but let anyone who wants to make up their own versioning scheme. `semver` would be an obvious extension.
Hm. That's a bit more complex than I had hoped, but it would mean ASDF systems would initially continue to work, it provides for some error checking, and a path to extension.
On 11/17/21 4:55 PM, Robert Goldman wrote:
On 17 Nov 2021, at 15:12, Eric Timmons wrote:
On 11/17/21 2:38 PM, Robert Goldman wrote: On 17 Nov 2021, at 13:31, Robert Dodier wrote: On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman rpgoldman@sift.info <mailto:rpgoldman@sift.info <mailto:rpgoldman@sift.info>> wrote: I favor something like this because it would be nice to have prerelease versions of ASDF that perform version checks properly. What I mean is, if we are going to add a feature in version 3.4, right now that would be in a prerelease version with a version number of something like 3.3.5.22 It would be a lot better for realistic testing if we could instead use 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that 3.4.0-1 comes before 3.4.0, not after. Hi Robert, hi everyone. I haven't been following closely, but while you are working out details, let me just mention that I recommend against version numbers that require special interpretation to discover their ordering, e.g. 3.4.0-1 < 3.4.0. Mostly I'm just thinking that somebody's not going to get the memo (it's usually me). For what it's worth, and all the best. I guess that would be an argument for using something more obvious than |-|, like the string |alpha| so |3.4.0-alpha1| or |3.4.0alpha1| instead of |3.4.0-1| since there the meaning should be relatively obvious. My feeling is that if a user misinterprets |3.4.0-1|, then shame on me. But if a user misinterprets |3.4.0alpha1| then shame on them. I'm not sure how that would align with semver... Erik already sent out some examples of ordering with semver. But it is worth noting that 3.4.0-1 *is* valid semver and the ordering would be 3.4.0-1 < 3.4.0-alpha So to prevent misinterpretation of 3.4.0-1, ASDF could either promise to always use something like alpha/beta/etc, use something else like PEP440 (I believe that grammar always requires an alphabetic character for pre-releases), or bake its own grammar. One thing that's nice about the semver grammar is its flexibility. I have some scripts that can generate a version string from a git repo that lets you easily order versions based on things like when they branched off the default branch. But if we want ASDF to disallow things like 3.4.0-1, I'm happy to build my own system that uses the new API to allow the use of semver strings. Another option is to choose something compatible with Debian's version strings. I'm having a little trouble grokking it at the moment, but it seems to be even more freeform than semver and adds an optional epoch prefix.What might be nice would be to support a /subset/ of semver by default -- not allowing the numerical prerelease flagged with |-| -- but do so in a way that is extensible.
Here's my rationale: I would like to provide a relatively simple semantic versioning that is also compatible with automatically detecting and rejecting ill-formed version strings.
So, for example, we could (by default!) split the version strings by |#.| and |#-| and /reject/ any string bounded by |#.| that is not numerical.
We could demand, again by default, that the substring following the |#-| be of some constrained form: e.g., Greek letter name followed by optional numeral. For that matter, we could just say "hey, alpha and beta are enough" and reject anything but those two. That would be a nice alternative to having a big table of Greek letter names in ASDF!
Finally, for those who want to really go for it, we could add a |:version-scheme| keyword to |defsystem|, which would initially default to |:unconstrained|, but then through the standard process of warning and then erroring, migrate to |:standard| (or perhaps |:asdf|) as the default, but let anyone who wants to make up their own versioning scheme. |semver| would be an obvious extension.
Hm. That's a bit more complex than I had hoped, but it would mean ASDF systems would initially continue to work, it provides for some error checking, and a path to extension.
I see what you're getting at. I already have the full semver parsing and ordering functionality implemented as part of !169. So I'd lean toward shipping :semver and :standard/:asdf out of the box.
:standard/:asdf would signal an error if the version string is not of the form X[-Y[.Z]]. Where X is a series of dot separated integers (what we have currently), Y is in [alpha, beta, rc], and Z is a single integer.
That would make :standard versioning a strict subset of :semver, with the same ordering relations. It also establishes clearly that we think alpha, beta, and rc are all that you need a vast majority of the time.
-Eric
That sounds like a great solution.
On 17 Nov 2021, at 16:33, Eric Timmons wrote:
On 11/17/21 4:55 PM, Robert Goldman wrote:
On 17 Nov 2021, at 15:12, Eric Timmons wrote:
On 11/17/21 2:38 PM, Robert Goldman wrote: On 17 Nov 2021, at 13:31, Robert Dodier wrote: On Wed, Nov 17, 2021 at 10:45 AM Robert Goldmanrpgoldman@sift.info <mailto:rpgoldman@sift.info mailto:rpgoldman@sift.info> wrote:
I favor something like this because it would be nice to have prerelease versions of ASDF that perform version checksproperly.
What I mean is, if we are going to add a feature in version3.4, right now that would be in a prerelease version with a version number of something like 3.3.5.22
It would be a lot better for realistic testing if we could instead use 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that 3.4.0-1 comes before 3.4.0, not after. Hi Robert, hi everyone. I haven't been following closely, butwhile you are working out details, let me just mention that I recommend against version numbers that require special interpretation to discover their ordering, e.g. 3.4.0-1 < 3.4.0.
Mostly I'm just thinking that somebody's not going to get thememo (it's usually me).
For what it's worth, and all the best. I guess that would be an argument for using something more obvious than |-|, like the string |alpha| so |3.4.0-alpha1|or |3.4.0alpha1| instead of |3.4.0-1| since there the meaning should be relatively obvious.
My feeling is that if a user misinterprets |3.4.0-1|, thenshame on me. But if a user misinterprets |3.4.0alpha1| then shame on them.
I'm not sure how that would align with semver... Erik already sent out some examples of ordering with semver. Butit is worth noting that 3.4.0-1 *is* valid semver and the ordering would be 3.4.0-1 < 3.4.0-alpha
So to prevent misinterpretation of 3.4.0-1, ASDF could either promise to always use something like alpha/beta/etc, usesomething else like PEP440 (I believe that grammar always requires an alphabetic character for pre-releases), or bake its own grammar.
One thing that's nice about the semver grammar is itsflexibility. I have some scripts that can generate a version string from a git repo that lets you easily order versions based on things like when they branched off the default branch. But if we want ASDF to disallow things like 3.4.0-1, I'm happy to build my own system that uses the new API to allow the use of semver strings.
Another option is to choose something compatible with Debian's version strings. I'm having a little trouble grokking it at the moment, but it seems to be even more freeform than semver andadds an optional epoch prefix.
What might be nice would be to support a /subset/ of semver by default -- not allowing the numerical prerelease flagged with |-| -- but do so in a way that is extensible.
Here's my rationale: I would like to provide a relatively simple semantic versioning that is also compatible with automatically detecting and rejecting ill-formed version strings.
So, for example, we could (by default!) split the version strings by |#.| and |#-| and /reject/ any string bounded by |#.| that is not numerical.
We could demand, again by default, that the substring following the |#-| be of some constrained form: e.g., Greek letter name followed by optional numeral. For that matter, we could just say "hey, alpha and beta are enough" and reject anything but those two. That would be a nice alternative to having a big table of Greek letter names in ASDF!
Finally, for those who want to really go for it, we could add a |:version-scheme| keyword to |defsystem|, which would initially default to |:unconstrained|, but then through the standard process of warning and then erroring, migrate to |:standard| (or perhaps |:asdf|) as the default, but let anyone who wants to make up their own versioning scheme. |semver| would be an obvious extension.
Hm. That's a bit more complex than I had hoped, but it would mean ASDF systems would initially continue to work, it provides for some error checking, and a path to extension.
I see what you're getting at. I already have the full semver parsing and ordering functionality implemented as part of !169. So I'd lean toward shipping :semver and :standard/:asdf out of the box.
:standard/:asdf would signal an error if the version string is not of the form X[-Y[.Z]]. Where X is a series of dot separated integers (what we have currently), Y is in [alpha, beta, rc], and Z is a single integer.
That would make :standard versioning a strict subset of :semver, with the same ordering relations. It also establishes clearly that we think alpha, beta, and rc are all that you need a vast majority of the time.
-Eric
Hi Anton,
On Fri, Nov 19, 2021 at 9:02 PM Anton Vodonosov avodonosov@yandex.ru wrote:
As I understand, this thread only discusses syntax and ordering rules for version numbers.
But if users see the :semver in ASDF examples and documentation, they will likely assume full semver practice is recommended by ASDF. As semver does not work for Common Lisp,
Could you elaborate a bit on "As semver does not work for Common Lisp"? I mean no programming language comes with "semver built in". It's the programmers that have to commit to "sticking to the semver rules" for it to work.
I am afraid such encouragement of its use will have lasting destructive effect on the ecosystem. So, if this new logic of version numbers is to be implemented, I would suggest to name it somehow differently.
Also, if the motivation is the desire to distinguish alpha versions from stable releases and have alpha ordered before the stable, the following approach makes it possible in the current versioning:
alpha version: 3.4.0-alpha beta version: 3.4.1-beta stable version: 3.4.2
In other words, never publish versions that have equal numeric parts. IMHO there is no significant practical sense in keeping even the least significant (patch) number equal between alpha and release.
semver is very much about API guarantees that are communicated by the version number. It's not "just" about the number. semver authors observed the desire from software authors to release new release lines as .0 or .0.0 and thereby a strong desire to be able to order version numbers *before* x.y.0 and x.0.0. The fact that there are other options available apparently was not a strong argument for those software authors. (btw, Perl has software version recognition built in dating from pre-semver and people work with that. However, many regret quite much that Perl - due to its built-in legacy - is unable to follow common practice. I think it makes sense for Common Lisp to recognize that semver is the predominant practice these days (while still recognizing others may not want to use version modifiers) and choose a setup which does not prevent its ecosystem to use semver at any future point.
Best regards,
- Anton
Best regards,
- Anton
Regards,
On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov avodonosov@yandex.ru wrote:
- etimmons@, rpgoldman@
"Erik Huelsmann" ehuels@gmail.com:
Could you elaborate a bit on "As semver does not work for Common Lisp"?
I've opened an issue in the SemVer github repo: https://github.com/semver/semver/issues/771 (Don't want to repeat this explanation over and over in many discussions).
"One bad programmer can break more than 10 good ones can fix": the issue you raise is bad engineering (increasing the version number simply because you can) and is not a problem semantic versioning is trying to solve. What it *does* try to solve is that the engineers working on the software can see the problems coming. Applications (and libraries) like Subversion have managed to stay within the boundaries of semantic versioning for almost 20 years now, still "stuck" at version 1.x because of it. At the same time they have succeeded to add significant new features to the software without breaking backward compatibility. So: it's possible. The fact that projects like e.g. Cucumber release a new major version every few months says more about those projects than about semver.
I will probably refine the issue description in the future, but it should be clear enough already.
Regards,
It shows that semantic versioning is a bad idea unless you have automatic ways of diffing an API between two versions (such tools exist for C), or the development team has the time and resources to very carefully evolve the code. What one finds in practice is that authors will wing it and increment version numbers if it "feels" like a major change or for publicity reasons (new major release, get it while it's hot!).
On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov avodonosov@yandex.ru wrote:
- etimmons@, rpgoldman@
"Erik Huelsmann" ehuels@gmail.com:
Could you elaborate a bit on "As semver does not work for Common Lisp"?
I've opened an issue in the SemVer github repo: https://github.com/semver/semver/issues/771 (Don't want to repeat this explanation over and over in many discussions).
"One bad programmer can break more than 10 good ones can fix": the issue you raise is bad engineering (increasing the version number simply because you can) and is not a problem semantic versioning is trying to solve. What it *does* try to solve is that the engineers working on the software can see the problems coming. Applications (and libraries) like Subversion have managed to stay within the boundaries of semantic versioning for almost 20 years now, still "stuck" at version 1.x because of it. At the same time they have succeeded to add significant new features to the software without breaking backward compatibility. So: it's possible. The fact that projects like e.g. Cucumber release a new major version every few months says more about those projects than about semver.
I will probably refine the issue description in the future, but it should be clear enough already.
Regards,
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
-- Stelian Ionescu
On Fri, Nov 19, 2021 at 10:08 PM Stelian Ionescu sionescu@cddr.org wrote:
It shows that semantic versioning is a bad idea
It's not a bad idea. It's badly executed. If humanity would be forbidden to start executing any good ideas because they will be executed badly, we wouldn't be doing anything today.
If a library says they adhere to semver and they make a mistake, that's a bug as much as a coding mistake is a bug. We have means to point this out to the authors, such as bug trackers. But: the fact that an author releases a version x.y.z doesn't by itself mean they adhere to semver. so maybe the author never intended you to assign this meaning to the version number...
Maybe we need a way for a system declaration to indicate whether its version adheres to semver or not?
Regards,
Erik.
unless you have automatic ways of diffing an API between two versions (such tools exist for C), or the development team has the time and resources to very carefully evolve the code. What one finds in practice is that authors will wing it and increment version numbers if it "feels" like a major change or for publicity reasons (new major release, get it while it's hot!).
On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov avodonosov@yandex.ru wrote:
- etimmons@, rpgoldman@
"Erik Huelsmann" ehuels@gmail.com:
Could you elaborate a bit on "As semver does not work for Common Lisp"?
I've opened an issue in the SemVer github repo: https://github.com/semver/semver/issues/771 (Don't want to repeat this explanation over and over in many discussions).
"One bad programmer can break more than 10 good ones can fix": the issue you raise is bad engineering (increasing the version number simply because you can) and is not a problem semantic versioning is trying to solve. What it *does* try to solve is that the engineers working on the software can see the problems coming. Applications (and libraries) like Subversion have managed to stay within the boundaries of semantic versioning for almost 20 years now, still "stuck" at version 1.x because of it. At the same time they have succeeded to add significant new features to the software without breaking backward compatibility. So: it's possible. The fact that projects like e.g. Cucumber release a new major version every few months says more about those projects than about semver.
I will probably refine the issue description in the future, but it should be clear enough already.
Regards,
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
-- Stelian Ionescu
On Fri, Nov 19, 2021 at 10:15 PM Erik Huelsmann ehuels@gmail.com wrote:
Maybe we need a way for a system declaration to indicate whether its version adheres to semver or not?
Anyway, the discussion seems to have drifted away from the original question whether versions should be sorted using the semver version modifier schema. That is: 1.0.0-alpha < 1.0.0-beta < 1.0.0-rc1 < 1.0.0-rc2 < 1.0.0
Which is a totally different matter than that ASDF or any other library should be using semver itself or that semver was a bad or a good idea.
My take here is that if someone releases 1.0.0-alpha *and* 1.0.0 then they probably did not intend 1.0.0-alpha to be sorted *after* (as newer than) 1.0.0.
On Fri, 19 Nov 2021 22:02:11 +0100 Erik Huelsmann ehuels@gmail.com wrote:
On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov avodonosov@yandex.ru wrote:
- etimmons@, rpgoldman@
"Erik Huelsmann" ehuels@gmail.com:
Could you elaborate a bit on "As semver does not work for Common Lisp"?
I've opened an issue in the SemVer github repo: https://github.com/semver/semver/issues/771 (Don't want to repeat this explanation over and over in many discussions).
"One bad programmer can break more than 10 good ones can fix": the issue you raise is bad engineering (increasing the version number simply because you can) and is not a problem semantic versioning is trying to solve. What it *does* try to solve is that the engineers working on the software can see the problems coming.
I disagree, in the example authentication-1.1.2 upgrades a dependency of commons-logging from 1.x to 2.x *because* commons-logging changed its API. Presumably authentication did *not* change it's API because it's following semver and only incremented the minor version. However, upgrading from authentication 1.1.1 to 1.1.2 will break if any other components depend on commons-logging-1.* since in Lisp (and many other languages) it's not possible to load two versions of the same system.
So long as two different versions of the same system cannot be used in the same image, this is a real problem with semver. How large of a problem it is can certainly be debated (I don't find it to be that big of an issue in practice).
-Jason
On 19 Nov 2021, at 15:25, Jason Miller wrote:
On Fri, 19 Nov 2021 22:02:11 +0100 Erik Huelsmann ehuels@gmail.com wrote:
On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov avodonosov@yandex.ru wrote:
- etimmons@, rpgoldman@
"Erik Huelsmann" ehuels@gmail.com:
Could you elaborate a bit on "As semver does not work for Common Lisp"?
I've opened an issue in the SemVer github repo: https://github.com/semver/semver/issues/771 (Don't want to repeat this explanation over and over in many discussions).
"One bad programmer can break more than 10 good ones can fix": the issue you raise is bad engineering (increasing the version number simply because you can) and is not a problem semantic versioning is trying to solve. What it *does* try to solve is that the engineers working on the software can see the problems coming.
I disagree, in the example authentication-1.1.2 upgrades a dependency of commons-logging from 1.x to 2.x *because* commons-logging changed its API. Presumably authentication did *not* change it's API because it's following semver and only incremented the minor version. However, upgrading from authentication 1.1.1 to 1.1.2 will break if any other components depend on commons-logging-1.* since in Lisp (and many other languages) it's not possible to load two versions of the same system.
So long as two different versions of the same system cannot be used in the same image, this is a real problem with semver. How large of a problem it is can certainly be debated (I don't find it to be that big of an issue in practice).
I'm not sure that I see this as a CL-specific problem. If you have a C++ program that uses one boost version and it uses a library that requires a different boost version, you have the same problem.
I also don't think that this is a problem with semantic versioning: the boost people use what we might call "anti-semantic versioning," but they still wreak havoc with the world. The problem isn't that semantic versioning breaks everything, the problem is that different libraries evolve at different rates, and that causes stuff to break.
I would argue that this shows the *strength* of semantic versioning: no, it doesn't magically solve the problem of version skew, but in at least some cases it tells you that you have version skew, and tells you where to look for a solution, instead of leaving you flailing around trying to figure out why your code has suddenly stopped working.
On 19 Nov 2021, at 15:25, Jason Miller wrote:
On Fri, 19 Nov 2021 22:02:11 +0100 Erik Huelsmann ehuels@gmail.com wrote:
On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov avodonosov@yandex.ru wrote:
- etimmons@, rpgoldman@
"Erik Huelsmann" ehuels@gmail.com:
Could you elaborate a bit on "As semver does not work for Common Lisp"?
I've opened an issue in the SemVer github repo: https://github.com/semver/semver/issues/771 (Don't want to repeat this explanation over and over in many discussions).
"One bad programmer can break more than 10 good ones can fix": the issue you raise is bad engineering (increasing the version number simply because you can) and is not a problem semantic versioning is trying to solve. What it *does* try to solve is that the engineers working on the software can see the problems coming.
I disagree, in the example authentication-1.1.2 upgrades a dependency of commons-logging from 1.x to 2.x *because* commons-logging changed its API. Presumably authentication did *not* change it's API because it's following semver and only incremented the minor version. However, upgrading from authentication 1.1.1 to 1.1.2 will break if any other components depend on commons-logging-1.* since in Lisp (and many other languages) it's not possible to load two versions of the same system.
So long as two different versions of the same system cannot be used in the same image, this is a real problem with semver. How large of a problem it is can certainly be debated (I don't find it to be that big of an issue in practice).
I'm not sure that I see this as a CL-specific problem. If you have a C++ program that uses one boost version and it uses a library that requires a different boost version, you have the same problem.
I also don't think that this is a problem with semantic versioning: the boost people use what we might call "anti-semantic versioning," but they still wreak havoc with the world. The problem isn't that semantic versioning breaks everything, the problem is that different libraries evolve at different rates, and that causes stuff to break.
I would argue that this shows the *strength* of semantic versioning: no, it doesn't magically solve the problem of version skew, but in at least some cases it tells you that you have version skew, and tells you where to look for a solution, instead of leaving you flailing around trying to figure out why your code has suddenly stopped working.
My personal experience is that semver is of no help because 1) authors don't really know when or how to increase the number, most have adopted semver because it's fashionable and 2) the users don't really know what the true minimum version is and just winge it by selecting whatever recent version they're working with as minimum requirement.
In the end both the release version and the dep versions are nothing more than suggeestions and the only sure way to know if integrating N libraries works is to try to load them all together and run their own test suites plus your application's test suite.
-- Stelian Ionescu
On 19 Nov 2021, at 15:43, Stelian Ionescu wrote:
In the end both the release version and the dep versions are nothing more than suggeestions and the only sure way to know if integrating N libraries works is to try to load them all together and run their own test suites plus your application's test suite.
I feel like this is, as my advisor used to say "reducing this to a previously unsolved problem"!
In my experience, testing is even less well-used than semantic versioning!
Anyway, none of this is going to make me keep semantic versioning support out of ASDF. Indeed, the current version comparison system is already "semver-lite," and I don't see how adding pre-release support is going to hurt anyone and it will *help* me test version-based checks in prerelease versions of ASDF.
So we can continue this discussion forever, but it won't change that.
Note that nothing we do -- or even *can* do -- would force anyone to use SemVer if they don't want to. But adding support will help the development of ASDF itself by letting us have well-behaved pre-release versions.
Happy weekend all
On Fri, Nov 19, 2021 at 10:43 PM Stelian Ionescu sionescu@cddr.org wrote:
I'm not sure that I see this as a CL-specific problem. If you have a C++
program that uses one boost version and it uses a library that requires a different boost version, you have the same problem.
I also don't think that this is a problem with semantic versioning: the
boost people use what we might call "anti-semantic versioning," but they still wreak havoc with the world. The problem isn't that semantic versioning breaks everything, the problem is that different libraries evolve at different rates, and that causes stuff to break.
I would argue that this shows the *strength* of semantic versioning: no,
it doesn't magically solve the problem of version skew, but in at least some cases it tells you that you have version skew, and tells you where to look for a solution, instead of leaving you flailing around trying to figure out why your code has suddenly stopped working.
My personal experience is that semver is of no help because 1) authors don't really know when or how to increase the number, most have adopted semver because it's fashionable and 2) the users don't really know what the true minimum version is and just winge it by selecting whatever recent version they're working with as minimum requirement.
In the end both the release version and the dep versions are nothing more than suggeestions and the only sure way to know if integrating N libraries works is to try to load them all together and run their own test suites plus your application's test suite.
I'm not sure how this is related to dependency declaration support in general: if you truely believe the information in the dependency declaration to be worthless, then there's no solution other than have everybody figure out their own dependency chains for themselves.
But if you're not going to use the information, then what are you objecting to?
Eric Timmons etimmons@mit.edu wrote:
So to prevent misinterpretation of 3.4.0-1, ASDF could either promise to always use something like alpha/beta/etc,
Then I suggest to also allow a, b, rc, and maybe p (for pre; equivalent of release candidate). That should cover a lot of ground.
Sorry but I am missing something.
It was said in this thread (don't remember who, apologies) that
YYYYMMDD
would work. Will it?
Cheers
Marco
On Thu, Nov 18, 2021 at 9:34 AM Didier Verna didier@lrde.epita.fr wrote:
Eric Timmons etimmons@mit.edu wrote:
So to prevent misinterpretation of 3.4.0-1, ASDF could either promise to always use something like alpha/beta/etc,
Then I suggest to also allow a, b, rc, and maybe p (for pre; equivalent of release candidate). That should cover a lot of ground.
-- Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
On 11/18/21 3:45 AM, Marco Antoniotti wrote:
Sorry but I am missing something.
It was said in this thread (don't remember who, apologies) that
YYYYMMDD
would work. Will it?
Yes. YYYYMMDD is currently a valid version string (assuming it's all digits). Whatever we choose will allow a superset of what's already allowed.
-Eric
Great, thanks!
On Thu, Nov 18, 2021 at 2:35 PM Eric Timmons etimmons@mit.edu wrote:
On 11/18/21 3:45 AM, Marco Antoniotti wrote:
Sorry but I am missing something.
It was said in this thread (don't remember who, apologies) that
YYYYMMDD
would work. Will it?
Yes. YYYYMMDD is currently a valid version string (assuming it's all digits). Whatever we choose will allow a superset of what's already allowed.
-Eric
On 18 Nov 2021, at 7:35, Eric Timmons wrote:
On 11/18/21 3:45 AM, Marco Antoniotti wrote:
Sorry but I am missing something.
It was said in this thread (don't remember who, apologies) that
YYYYMMDD
would work. Will it?
Yes. YYYYMMDD is currently a valid version string (assuming it's all digits). Whatever we choose will allow a superset of what's already allowed.
-Eric
That's true, but possibly stating the obvious: ASDF does not "understand" a version string like that. So you can't say "any version since October 2020 will work." Getting something like that to work would be an exercise for the extension protocol.
This actually might make a good test case for us to see if the proposed protocol (versioning method keyword initarg for defsystem) makes sense.
R
Why would ASDF not understand "version later than 20201015"? I am perfectly fine with using the full 8 digit timestamp.
MA
On Thu, Nov 18, 2021 at 4:24 PM Robert Goldman rpgoldman@sift.info wrote:
On 18 Nov 2021, at 7:35, Eric Timmons wrote:
On 11/18/21 3:45 AM, Marco Antoniotti wrote:
Sorry but I am missing something.
It was said in this thread (don't remember who, apologies) that
YYYYMMDD
would work. Will it?
Yes. YYYYMMDD is currently a valid version string (assuming it's all digits). Whatever we choose will allow a superset of what's already allowed.
-Eric
That's true, but possibly stating the obvious: ASDF does not "understand" a version string like that. So you can't say "any version since October 2020 will work." Getting something like that to work would be an exercise for the extension protocol.
This actually might make a good test case for us to see if the proposed protocol (versioning method keyword initarg for defsystem) makes sense.
R
What I meant is that ASDF does not "understand" that 20201015 is a three-part version, whose first part is "2020" second is "10" and third is "15".
So note that my example is "any version since October 2020." And yours is "any version since October *fifteenth* 2020.
On 18 Nov 2021, at 10:53, Marco Antoniotti wrote:
Why would ASDF not understand "version later than 20201015"? I am perfectly fine with using the full 8 digit timestamp.
MA
On Thu, Nov 18, 2021 at 4:24 PM Robert Goldman rpgoldman@sift.info wrote:
On 18 Nov 2021, at 7:35, Eric Timmons wrote:
On 11/18/21 3:45 AM, Marco Antoniotti wrote:
Sorry but I am missing something.
It was said in this thread (don't remember who, apologies) that
YYYYMMDD
would work. Will it?
Yes. YYYYMMDD is currently a valid version string (assuming it's all digits). Whatever we choose will allow a superset of what's already allowed.
-Eric
That's true, but possibly stating the obvious: ASDF does not "understand" a version string like that. So you can't say "any version since October 2020 will work." Getting something like that to work would be an exercise for the extension protocol.
This actually might make a good test case for us to see if the proposed protocol (versioning method keyword initarg for defsystem) makes sense.
R
-- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY
I understand: I am not expecting ASDF to understand any three part version in my case.
I'd wager that most cases are covered by the 8-digit timestamp scheme.
All the best
Marco
On Thu, Nov 18, 2021 at 5:57 PM Robert Goldman rpgoldman@sift.info wrote:
What I meant is that ASDF does not "understand" that 20201015 is a three-part version, whose first part is "2020" second is "10" and third is "15".
So note that my example is "any version since October 2020." And yours is "any version since October *fifteenth* 2020.
On 18 Nov 2021, at 10:53, Marco Antoniotti wrote:
Why would ASDF not understand "version later than 20201015"? I am perfectly fine with using the full 8 digit timestamp.
MA
On Thu, Nov 18, 2021 at 4:24 PM Robert Goldman rpgoldman@sift.info wrote:
On 18 Nov 2021, at 7:35, Eric Timmons wrote:
On 11/18/21 3:45 AM, Marco Antoniotti wrote:
Sorry but I am missing something.
It was said in this thread (don't remember who, apologies) that
YYYYMMDD
would work. Will it?
Yes. YYYYMMDD is currently a valid version string (assuming it's all digits). Whatever we choose will allow a superset of what's already allowed.
-Eric
That's true, but possibly stating the obvious: ASDF does not "understand" a version string like that. So you can't say "any version since October 2020 will work." Getting something like that to work would be an exercise for the extension protocol.
This actually might make a good test case for us to see if the proposed protocol (versioning method keyword initarg for defsystem) makes sense.
R
-- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY
I assume "any version since October 2020" would be written something like "version later than or equal to 20201001"
Or maybe "version later than or equal to 20201101" if that's what "since October 2020" means :-)
__Martin
On Thu, 18 Nov 2021 10:57:45 -0600, Robert Goldman said:
What I meant is that ASDF does not "understand" that 20201015 is a three-part version, whose first part is "2020" second is "10" and third is "15".
So note that my example is "any version since October 2020." And yours is "any version since October *fifteenth* 2020.
On 18 Nov 2021, at 10:53, Marco Antoniotti wrote:
Why would ASDF not understand "version later than 20201015"? I am perfectly fine with using the full 8 digit timestamp.
MA
On Thu, Nov 18, 2021 at 4:24 PM Robert Goldman rpgoldman@sift.info wrote:
On 18 Nov 2021, at 7:35, Eric Timmons wrote:
On 11/18/21 3:45 AM, Marco Antoniotti wrote:
Sorry but I am missing something.
It was said in this thread (don't remember who, apologies) that
YYYYMMDD
would work. Will it?
Yes. YYYYMMDD is currently a valid version string (assuming it's all digits). Whatever we choose will allow a superset of what's already allowed.
-Eric
That's true, but possibly stating the obvious: ASDF does not "understand" a version string like that. So you can't say "any version since October 2020 will work." Getting something like that to work would be an exercise for the extension protocol.
This actually might make a good test case for us to see if the proposed protocol (versioning method keyword initarg for defsystem) makes sense.
R
-- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY
On 11/17/21 10:55 AM, Eric Timmons wrote:
Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner.
Sorry all, I didn't mean for this to descend into chaos.
I'll put together a summary of what may plan in this area is, along with a rationale. I'm a bit busy at the moment, but I expect I can email it out within the next couple days.
If nothing else, it'll give us something concrete to discuss.
-Eric
-
Andreas Davour -
Anton Vodonosov -
Didier Verna -
Eric Timmons -
Erik Huelsmann -
Jason Miller -
Marco Antoniotti -
Martin Simmons -
Robert Dodier -
Robert Goldman -
Stelian Ionescu