Re: Versioning

[Erik Huelsmann]

On Fri, Nov 19, 2021 at 10:43 PM Stelian Ionescu  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?

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Re: Versioning

[Erik Huelsmann]

On Fri, Nov 19, 2021 at 10:15 PM Erik Huelsmann  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.

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Re: Versioning

[Erik Huelsmann]

On Fri, Nov 19, 2021 at 10:08 PM Stelian Ionescu  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 
> wrote:
>
> - etimmons@, rpgoldman@
>
> "Erik Huelsmann" :
> > 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
>
>

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Re: Versioning

[Erik Huelsmann]

On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov 
wrote:

> - etimmons@, rpgoldman@
>
> "Erik Huelsmann" :
> > 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.

Re: Versioning

[Erik Huelsmann]

Hi Anton,

On Fri, Nov 19, 2021 at 9:02 PM Anton Vodonosov 
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,

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Re: Next steps

[Erik Huelsmann]

>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  wrote:

> On 17 Nov 2021, at 13:31, Robert Dodier wrote:
>
> On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman rpgold...@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...
>


-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Re: Implementor emails

[Erik Huelsmann]

Hi Robert,

On Sat, Jul 3, 2021 at 7:34 PM Robert Goldman  wrote:

> My email to the Corman Lisp address bounced, so I am dropping Corman
> Lisp from the mailing list, unless someone can point me at a working
> contact email.
>
> Also -- my emails to the various implementation development mailing
> lists are all on hold waiting for moderator approval (CCL, ABCL, clasp,
> ECL, CMUCL).  Moderators -- if you are on this list, please add me to
> the accept list for your mailing list; I promise I won't abuse it, but I
> cannot spare the time to join all the implementations' mailing lists.
>

For some of the lists on common-lisp.net, I was able to figure out why your
mail was added to the moderation queue. In many cases you *were* added to
the allow-list, but your mail had too many recipients to be allowed through
automatically.

Hope that sheds some light!

Regards,

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Re: Syntax control code

[Erik Huelsmann]

gitlab is back up now.

Regards,

Erik.

On Sun, Jan 7, 2018 at 12:39 PM, Faré  wrote:

> It's in doc/syntax-control.md in the syntax-control branch (MR !86 on
> gitlab).
> Unhappily, gitlab.common-lisp.net seems to be down right now:
> https://gitlab.common-lisp.net/asdf/asdf
> If symptom persists, you may have to use my github backup in the meantime.
> https://github.com/fare/asdf/blob/syntax-control/doc/syntax-control.md
>
> —♯ƒ • François-René ÐVB Rideau •Reflection•
> http://fare.tunes.org
> From a programmer's point of view, the user is a peripheral that types
> when you issue a read request. — P. Williams
>
>
> On Sun, Jan 7, 2018 at 5:24 AM, 73budden .  wrote:
> > Hi! Where the document is found?
> >
> > 2018-01-06 3:53 GMT+03:00, Robert Goldman :
> >> I just pushed an edit of syntax-control.md in which I try to capture
> the
> >> terminology.
> >>
> >> Status: several Allegro failures break for me on test-syntax-control.
> >> Results from Linux:
> >>
> >> build/results/allegro8_64-test.text
> >> build/results/allegro8_64_s-test.text
> >> build/results/allegromodern8_64-test.text
> >> build/results/allegromodern8_64_s-test.text
> >> build/results/allegromodern_64-test.text
> >> build/results/allegromodern_64_s-test.text
> >>
> >> These failures seem to be due to NAMED-READTABLES not working properly
> >> on these platforms, rather than on anything ASDF itself does.
> >>
> >> Concern:  As I was reading over syntax-control.md, it was brought home
> >> to me that the ASDF shared syntax is initialized to the *initial syntax*
> >> on the host implementation, rather than the standard syntax of ANSI CL.
> >> My understanding is that this is done for backwards-compatibility with
> >> some QL systems that assume they have access to extended syntax from
> >> some implementation(s).  I'm concerned that this will create a
> >> maintenance headache going forward just so someone *else* can avoid
> >> making some minor clean-up.  Should we just suck it up and make the
> >> shared syntax start out with the initial syntax?  Why not break it now,
> >> and save ourselves trouble later?  Also, it seems like "initial syntax"
> >> is not well-defined, even on a single implementation, since ASDF might
> >> be loaded at arbitrary times, possibly after modifications to the
> >> "initial initial" readtable.  Finally, going forward, people will be
> >> yelling at *us* if implementations change their initial syntax.
> >>
> >> Unless there's a really important reason to keep this, I think we should
> >> kill it.
> >>
> >>
> >
>
>


-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Re: Purpose of components of type :static-file?

[Erik Huelsmann]

Hi Dave,

Thanks for asking! Many systems seem to depend on files existing on the
disk system near the .asd file. However, systems shouldn't depend on
that, as e.g. ABCL implements the asdf :bundle-op operation, which compiles
an entire system into one monolithic FASL file (which can then be included
in a JAR). Back when I did the implementation for :bundle-op I remember
people objecting (it being an excercise in futility) because too many
systems depend on the previously described behaviour.

Herewith, I'd like system authors to take note and use the :static-file
declaration so systems like ECL and ABCL for which it makes sense to
compile monolithic bundles for general distribution can include those
resources in the bundle.


Regards,



Erik.




On Tue, May 26, 2015 at 6:29 PM, Dave Cooper david.coo...@genworks.com
wrote:


 Hi,

 What is the intended purpose of the :static-files component-type in ASDF?
 I see a couple examples of their use in the ASDF manual, but didn't see an
 explanation or real example of how to use them downstream from including
 them in the defsystem form in the .asd file.

 Presumably they can be used for README, license, example files, and other
 resources which go with a system but are not Lisp source files to be
 compiled and loaded with the system.

 If so, then what are the supported/expected operations with static-files?
 For example, is there a way to query a system for files of type
 :static-file, so that you can do something with them (e.g. copy them to a
 distribution directory)?

 Best Regards,

  Dave

 P.S. my apologies if this has been discussed in this list before


 --
 My Best,

 Dave Cooper, Genworks Support
 david.coo...@genworks.com, dave.genworks.com(skype)
 +1 248-330-2979




-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Re: [Asdf-devel] :homepage :bug-tracker :mailto :long-name :source-control

[Erik Huelsmann]

Hi Faré,

Interesting thing to learn that they actually existed. Never knew and I
actually thought about sending a request to the ASDF mailing list to that
extent to mirror the metadata that's commonly included in Perl modules.
With these fields, the already known description field and the
dependencies list, it would be possible to start a nice metadata site like
metacpan.org -- with the notable difference that we don't have a CPAN.org,
so people would have to register their own packages. Kickstarting with
quicklisp projects could be a nice seed for the site.

Regards,

Erik.

On Thu, Dec 18, 2014 at 6:03 AM, Faré fah...@gmail.com wrote:

 Shamed by a tweet by @hexstreamsoft, I made a very minimal attempt at
 documenting the existence since ASDF 2.27 of the :homepage
 :bug-tracker :mailto :long-name :source-control keywords to defsystem.
 I will leave for someone else to make real manual entries out of the
 information. NB: AFAIR, none of the types of these arguments is
 enforced by ASDF.

 Good luck!

 —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics•
 http://fare.tunes.org
 Efficiency is doing things right; effectiveness is doing the right things.
 — Peter Drucker

 ___
 Asdf-devel mailing list
 Asdf-devel@common-lisp.net
 http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel




-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] :homepage :bug-tracker :mailto :long-name :source-control

[Erik Huelsmann]

Hi Robert,

On Sun, Mar 8, 2015 at 4:29 PM, Robert P. Goldman rpgold...@sift.net
wrote:

 Interestingly, while we have the new metadata options listed in the
 grammar now, I see that the :version option is missing (although
 documented in text).


Where were you looking? Because I was looking here:
https://common-lisp.net/project/asdf/asdf/The-defsystem-grammar.html#The-defsystem-grammar
and there I'm not finding the :version or :description or :author
attributes in the grammar. Am I looking in the wrong place?



-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] ASDF:SYSTEM-RELATIVE-PATHNAME in deployment scenarios

[Erik Huelsmann]

Resending in order to get the message on asdf-devel@

On Thu, Apr 4, 2013 at 11:33 PM, Erik Huelsmann ehu...@gmail.com wrote:

 Hi,


 Today Mark and I were discussing the new ASDF3 capabilities which should
 help with deployment: the monolithic-fasl-op, binary-op and others.

 While I do see lots of potential for the monolithic fasl op for code-only
 deployment situations, Mark and Anton brought up scenarios where a system
 may consist of code and resources. The code may choose to access such
 resources at run time through the use of the SYSTEM-RELATIVE-PATHNAME
 facility.

 Because I don't have an immediate answer myself yet (I'm just now learning
 about this facility), I'm directing our discussion to asdf-devel@. How do
 see this scenario?


 Bye,

 Erik.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel