The ASD file for Alexandria mentions that is has version "0.0.0", which is crazy to have for the most popular Quicklisp library and perhaps the most famous Lisp one.
https://github.com/keithj/alexandria/blob/master/alexandria.asd#L2
I call for this to be fixed.
~phoe
While we're at it, I also have had for a few months this patch to simplify the .asd file given ASDF 3 capabilities (i.e. only compatible with 2013 or later).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Social peace will come when the socialists will love the poor more than they hate the rich. — Not Golda Meir
On Mon, Aug 14, 2017 at 1:47 PM, Michał "phoe" Herda phoe@teknik.io wrote:
The ASD file for Alexandria mentions that is has version "0.0.0", which is crazy to have for the most popular Quicklisp library and perhaps the most famous Lisp one.
https://github.com/keithj/alexandria/blob/master/alexandria.asd#L2
I call for this to be fixed.
~phoe
The ASD file for Alexandria mentions that is has version "0.0.0", which
i've pushed Fare's .asd simplifications, but the versioning is not that trivial. Nikodemus has come up with a versioning scheme where the package is also called :alexandria.0.dev with an :alexandria nickname.
i'm not sure what exactly was the plan, and whether it's written up somewhere, so i'll not jump into just overwriting the :version field in the .asd.
is there anyone who remembers/knows?
if not, then any suggestions what the next version should be in the .asd, and what to do with the package?
On Mon, Aug 14, 2017 at 4:46 PM, Attila Lendvai attila@lendvai.name wrote:
The ASD file for Alexandria mentions that is has version "0.0.0", which
[…] the versioning is not that trivial. Nikodemus has come up with a versioning scheme where the package is also called :alexandria.0.dev with an :alexandria nickname.
i'm not sure what exactly was the plan, and whether it's written up somewhere, so i'll not jump into just overwriting the :version field in the .asd.
is there anyone who remembers/knows?
if not, then any suggestions what the next version should be in the .asd, and what to do with the package?
May I suggest that this package naming scheme is bullshit and that no one uses it, nor is anyone susceptible of using it in the near or far future?
Until someone comes up with actual usage patterns (or, better, functions and macros) to use this kind of package versioning, it's better to get rid of it.
However, getting rid of it is not something to do lightly, so what about increasing the asdf version to 0.1.0, then 0.1.1 at next "release", etc., and go to 0.2.0 whenever some less than "compatible" API change is done, etc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Whatever says the law, it is only ever forbidden but to get caught.
I'd like to note that this ".0.dev" versioning scheme was AFAIK *never* used to create more than *one* version of Alexandria.
With all due respect to the author of the versioning system, I consider the current system to be a bug rather than a feature if it prevents anyone, including Alexandria maintainers itself, from finding out what the current version of Alexandria is and what the next version of Alexandria should be.
I agree with Fare.
~phoe
On 15.08.2017 04:40, Faré wrote:
On Mon, Aug 14, 2017 at 4:46 PM, Attila Lendvai attila@lendvai.name wrote:
The ASD file for Alexandria mentions that is has version "0.0.0", which
[…] the versioning is not that trivial. Nikodemus has come up with a versioning scheme where the package is also called :alexandria.0.dev with an :alexandria nickname.
i'm not sure what exactly was the plan, and whether it's written up somewhere, so i'll not jump into just overwriting the :version field in the .asd.
is there anyone who remembers/knows?
if not, then any suggestions what the next version should be in the .asd, and what to do with the package?
May I suggest that this package naming scheme is bullshit and that no one uses it, nor is anyone susceptible of using it in the near or far future?
Until someone comes up with actual usage patterns (or, better, functions and macros) to use this kind of package versioning, it's better to get rid of it.
However, getting rid of it is not something to do lightly, so what about increasing the asdf version to 0.1.0, then 0.1.1 at next "release", etc., and go to 0.2.0 whenever some less than "compatible" API change is done, etc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Whatever says the law, it is only ever forbidden but to get caught.
alexandria-devel@common-lisp.net
-
Attila Lendvai -
Faré -
Michał "phoe" Herda