www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dub and '1.2.3' type version tags

reply FeepingCreature <feepingcreature gmail.com> writes:
Semver 2.0.0 ( https://semver.org/ ) no longer requires the 
leading 'v' in version tags. What's the opinion of the community 
on whether dub should be changed to follow suit, ie. not require 
'v' as well? (It's a trivial change code-wise.)
Nov 25 2019
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 25/11/2019 10:11 PM, FeepingCreature wrote:

 Semver 2.0.0 ( https://semver.org/ ) no longer requires the leading 'v' 
 in version tags. What's the opinion of the community on whether dub 
 should be changed to follow suit, ie. not require 'v' as well? (It's a 
 trivial change code-wise.)


I see no reason not to make it optional and it makes it a tad easier to 
work with.
Nov 25 2019
prev sibling next sibling parent S.G <S.G sdfsdfsfsdfsdf.gs> writes:
On Monday, 25 November 2019 at 09:11:06 UTC, FeepingCreature 
wrote:

 Semver 2.0.0 ( https://semver.org/ ) no longer requires the 
 leading 'v' in version tags. What's the opinion of the 
 community on whether dub should be changed to follow suit, ie. 
 not require 'v' as well? (It's a trivial change code-wise.


Yes it should.

The 'v' allows an early detection of invalid cases. if not 'v' 
then [0-9], bam you can reject directly. But since we don't talk 
about parsing 10 Megs of data that's just doesn't really matter.
Nov 25 2019
prev sibling next sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Monday, 25 November 2019 at 09:11:06 UTC, FeepingCreature 
wrote:

 Semver 2.0.0 ( https://semver.org/ ) no longer requires the 
 leading 'v' in version tags. What's the opinion of the 
 community on whether dub should be changed to follow suit, ie. 
 not require 'v' as well? (It's a trivial change code-wise.)


I am ok with it. There might be some custom tooling around dub 
that expects a leading 'v', although I can't think of anything.
Nov 25 2019
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 25 November 2019 at 13:03:38 UTC, Sebastiaan Koppe 
wrote:

 There might be some custom tooling around dub that expects a 
 leading 'v', although I can't think of anything.


My dpldocs.info uses it to differentiate custom version 
subdomains vs files, but it could just as well do that by 
checking for a numeric pattern in the url, so I don't object to 
the change.
Nov 25 2019
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/25/19 4:11 AM, FeepingCreature wrote:

 Semver 2.0.0 ( https://semver.org/ ) no longer requires the leading 'v' 
 in version tags. What's the opinion of the community on whether dub 
 should be changed to follow suit, ie. not require 'v' as well? (It's a 
 trivial change code-wise.)


I've done it several times where I tag without the v, and code.dlang.org 
fails to pick it up.

I'm in favor.

-Steve
Nov 25 2019
prev sibling next sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Monday, 25 November 2019 at 09:11:06 UTC, FeepingCreature 
wrote:

 Semver 2.0.0 ( https://semver.org/ ) no longer requires the 
 leading 'v' in version tags. What's the opinion of the 
 community on whether dub should be changed to follow suit, ie. 
 not require 'v' as well? (It's a trivial change code-wise.)


It should either require it or not. As it has been required 
historically it should remain required.

Making it optional creates complications for tooling. Consistency 
in our ecosystem will be most important.
Nov 25 2019
parent reply mipri <mipri minimaltype.com> writes:
On Tuesday, 26 November 2019 at 02:13:42 UTC, Jesse Phillips 
wrote:

 On Monday, 25 November 2019 at 09:11:06 UTC, FeepingCreature
 wrote:

 Semver 2.0.0 ( https://semver.org/ ) no longer requires the
 leading 'v' in version tags. What's the opinion of the
 community on whether dub should be changed to follow suit, ie.
 not require 'v' as well? (It's a trivial change code-wise.)


 It should either require it or not. As it has been required
 historically it should remain required.

 Making it optional creates complications for tooling.
 Consistency in our ecosystem will be most important.


dub says it uses SemVer, though, and SemVer changed. So we
don't have a choice of whether to be consistent or
inconsistent, but about what to be inconsistent with: the new
or the old. Over time, and especially since dub.pm points to
semver.org to justify the version requirements it has, the
inconsistency with the new will cause more problems.

And, "no longer requires" is putting it gently. semver.org
actually says:

Q: Is “v1.2.3” a semantic version?
A: No, “v1.2.3” is not a semantic version.

Now, compare this with the 1.0.0 doc, which

.
.
.

erm.

It doesn't mention 'v' at all. It just talks about 1.2.3
versions. The only 'v' is in the URL. Also the URL for the
*new* version of semver is

https://semver.org/spec/v2.0.0.html
                         ^
                         |
                         eh?

Also, after the Q&A that I quoted before, it says:


 However, prefixing a semantic version with a “v” is a common
 way (in English) to indicate it is a version number.
 Abbreviating “version” as “v” is often seen with version
 control. Example: git tag v1.2.3 -m "Release version 1.2.3", in
 which case “v1.2.3” is a tag name and the semantic version is
 “1.2.3”.


What's the problem again?
Nov 25 2019
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 26 November 2019 at 02:58:52 UTC, mipri wrote:

 What's the problem again?


Dub does not utilize the v

https://github.com/llJochemll/quirks/blob/master/dub.json#L12

But I'm really confused what side you are arguing. You state that 
using v is not semantic version 2 but then show they use it and 
note it is a legitimate to us in tags as shorthand for version.

So where is dub violating sem ver 2?
Nov 25 2019
parent reply mipri <mipri minimaltype.com> writes:
On Tuesday, 26 November 2019 at 04:05:39 UTC, Jesse Phillips 
wrote:

 But I'm really confused what side you are arguing.


dub requires version tags to have a 'v' prefix to semver
versions. semver has never required this, and still does not
require it.  What has changed with version 2.0 is that semver
documents the practice of having a 'v'. Incidentally semver's
website also follows this practice.

So actually, nothing important for dub has changed with version
2 of semver, contrary to the suggestion of this thread that dub
follow suit with some change in semver.

The question can still be: should dub drop this requirement.

Of the requirement itself, I wouldn't mind either way. What's
more important to me is that dub be actively maintained. On
balance, between "tools (what tools?) become slightly more
inconsistent for a while" or "dub doesn't get important updates
because people see that even trivial updates like this one
can't get done", I want the important updates.
Nov 25 2019
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 26 November 2019 at 04:16:39 UTC, mipri wrote:

 Of the requirement itself, I wouldn't mind either way. What's
 more important to me is that dub be actively maintained. On
 balance, between "tools (what tools?) become slightly more
 inconsistent for a while" or "dub doesn't get important updates
 because people see that even trivial updates like this one
 can't get done", I want the important updates.


I think a large part of the problem is that dub is effectively 
unmaintained. To be honest, as soon as I saw one person 
disagreeing I groaned and thought to myself "great, I'll never 
get this in now." My impression is that as things stand, dub is 
in "maintenance mode" - which effectively means that dub changes 
can only be merged in the presence of perfect consensus. Who has 
responsibility over dub? Who "owns" the code? Who can decide what 
goes in and what stays out in the absence of perfect agreement? 
Who can we appeal to with our usecases? By my impression, there 
is no such person, and this presents a severe flaw in the D 
ecosystem.
Nov 25 2019
parent reply bachmeier <no spam.net> writes:
On Tuesday, 26 November 2019 at 07:23:08 UTC, FeepingCreature 
wrote:


 I think a large part of the problem is that dub is effectively 
 unmaintained. To be honest, as soon as I saw one person 
 disagreeing I groaned and thought to myself "great, I'll never 
 get this in now." My impression is that as things stand, dub is 
 in "maintenance mode" - which effectively means that dub 
 changes can only be merged in the presence of perfect 
 consensus. Who has responsibility over dub? Who "owns" the 
 code? Who can decide what goes in and what stays out in the 
 absence of perfect agreement? Who can we appeal to with our 
 usecases? By my impression, there is no such person, and this 
 presents a severe flaw in the D ecosystem.


When I've visited the repo in the past, I've come away with the 
impression that the project is dead. I just commented on a couple 
of bug reports that should be closed. It's unlikely that there 
will even be a response to my comments. I could have just as well 
posted on an IRC channel where I'm the only participant. This is 
an embarrassing situation for the language.

It's time to move on from Dub. The D community is at this stage 
not capable of supporting such an ambitious project. Heck, we 
can't even provide real documentation, and that alone drives 
people away. We should as much as possible use infrastructure 
provided by other open source projects and worry about making the 
minor customizations needed to get it to work for our needs.

Some will say Dub works for them. Some will proclaim that it is a 
great piece of work. Nothing prevents them from continuing to use 
Dub to build simple D-only projects. There is no chance Dub will 
ever be a general purpose solution. Sometimes it's best to admit 
defeat and move on.
Nov 26 2019
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 26 November 2019 at 10:23:04 UTC, bachmeier wrote:

 When I've visited the repo in the past, I've come away with the 
 impression that the project is dead. I just commented on a 
 couple of bug reports that should be closed. It's unlikely that 
 there will even be a response to my comments. I could have just 
 as well posted on an IRC channel where I'm the only 
 participant. This is an embarrassing situation for the language.

 It's time to move on from Dub. The D community is at this stage 
 not capable of supporting such an ambitious project. Heck, we 
 can't even provide real documentation, and that alone drives 
 people away. We should as much as possible use infrastructure 
 provided by other open source projects and worry about making 
 the minor customizations needed to get it to work for our needs.


So what replacement project that does builds, tests and version 
management (including downloads and version management) do you 
propose?
Nov 26 2019
parent bachmeier <no spam.net> writes:
On Tuesday, 26 November 2019 at 11:28:36 UTC, FeepingCreature 
wrote:


 So what replacement project that does builds, tests and version 
 management (including downloads and version management) do you 
 propose?


Dub replacements have been discussed numerous times on the 
mailing list. I'm not qualified to make a recommendation. My 
point is that Dub has failed because its needs exceed the 
resources of the community, so we need to outsource as much of it 
as possible.
Nov 26 2019
prev sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 25.11.2019 um 10:11 schrieb FeepingCreature:

 Semver 2.0.0 ( https://semver.org/ ) no longer requires the leading 'v' 
 in version tags. What's the opinion of the community on whether dub 
 should be changed to follow suit, ie. not require 'v' as well? (It's a 
 trivial change code-wise.)


I don't think SemVer ever required a "v" prefix. The reason it is 
required by dub is on one hand that it is common practice and on the 
other hand it leaves the possibility to have version branches that can 
be clearly distinguished from tags.

Any number of other schemes could do the same thing, but I don't think 
it's a good idea to introduce inconsistency into the system without a 
very good reason. It may not be as bad as the awful JSON/SDLang split 
that happened previously due to wanting to cater all tastes, but it goes 
into the same direction.
Nov 26 2019