digitalmars.D - Dub and '1.2.3' type version tags
- FeepingCreature (4/4) Nov 25 2019 Semver 2.0.0 ( https://semver.org/ ) no longer requires the
- rikki cattermole (3/7) Nov 25 2019 I see no reason not to make it optional and it makes it a tad easier to
- S.G (6/10) Nov 25 2019 Yes it should.
- Sebastiaan Koppe (4/8) Nov 25 2019 I am ok with it. There might be some custom tooling around dub
- Adam D. Ruppe (6/8) Nov 25 2019 My dpldocs.info uses it to differentiate custom version
- Steven Schveighoffer (5/9) Nov 25 2019 I've done it several times where I tag without the v, and code.dlang.org...
- Jesse Phillips (6/10) Nov 25 2019 It should either require it or not. As it has been required
- mipri (26/42) Nov 25 2019 dub says it uses SemVer, though, and SemVer changed. So we
- Jesse Phillips (7/8) Nov 25 2019 Dub does not utilize the v
- mipri (17/18) Nov 25 2019 dub requires version tags to have a 'v' prefix to semver
- FeepingCreature (12/18) Nov 25 2019 I think a large part of the problem is that dub is effectively
- bachmeier (19/30) Nov 26 2019 When I've visited the repo in the past, I've come away with the
- FeepingCreature (4/16) Nov 26 2019 So what replacement project that does builds, tests and version
- bachmeier (7/10) Nov 26 2019 Dub replacements have been discussed numerous times on the
- =?UTF-8?Q?S=c3=b6nke_Ludwig?= (10/14) Nov 26 2019 I don't think SemVer ever required a "v" prefix. The reason it is
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
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
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
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
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
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
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
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: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: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.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
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
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
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
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
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
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
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