Re: Computing the next SemVer for dlang packages with dsemver
Am 22.10.2020 um 17:50 schrieb Sönke Ludwig: with the drawback that there is no supported means to still provide something like a distinction between breaking (x) and non-breaking (y) changes. * with supported I mean that you can use `~>0.x.y` to restrict to a certain x, which would be less obvious for something like 1.0.0-alpha.x.y.
Re: Computing the next SemVer for dlang packages with dsemver
Am 22.10.2020 um 10:59 schrieb Robert burner Schadek: On Wednesday, 21 October 2020 at 17:55:00 UTC, Sönke Ludwig wrote: 0.x.y vs. 1+.x.y is about the development process/state. Quite often a design is not yet fully fleshed out in the beginning and there are many incremental changes to the API. If 0.x.y didn't exist, that would simply mean that either the project gets more or less stuck with the initial (bad) design, or that it quickly increments major versions, effectively providing no more stability as in the 0.x.y case. I think that is the one mistake SemVer does. 0.x.y is just one big loophole. After the 1.x.y release an breaking api change requires a major version increment. The way it should be. Stability or unstable is only mentioned in the 0.x.y definitions. You are not stuck on a bad design, break the api, improve the api, increment the major version number. If you break the api in an 0.x.y version the hard part does not change. In both instances the users have to update their usage. In know in theory 0.x.y should be considered unstable. But by amount of 0.x.y we have you pretty much can't get anything done in D if you only use stable packages. The loophole has become the normal case. So what can we do, I see two major options: 1. we can live on the edge and use unstable packages and have no meaning in the SemVer number 2. we can acknowledge that most of them are stable, put a 1. in front and ignore the 0.x.y part of the SemVer definition and have the SemVer mean something dsemver does 2. And true there might be cases where dsemver does not increment the number correctly, but you can always increment by hand. Also if your api is not stable after your 1.x.y release and you break everything in 2.x.y, so what. Your users are also annoyed when you break your api from 0.1.x to 0.1.1. Only difference is they could have seen in coming by looking at the SemVer. I should stop ranting now. The real alternative to 0.x.y is 1.0.0-alpha.1+, though, with the drawback that there is no supported means to still provide something like a distinction between breaking (x) and non-breaking (y) changes. There is also value in having some kind of indicator that the code has reached a certain level of maturity (1.0.0).
Highlight general point about software dev and design in general.
On Tuesday, 20 October 2020 at 21:58:16 UTC, Johan Engelen wrote:
On Tuesday, 20 October 2020 at 20:21:56 UTC, aberba wrote:
On Tuesday, 20 October 2020 at 17:36:11 UTC, kinke wrote:
On Tuesday, 20 October 2020 at 16:08:47 UTC, aberba wrote:
It's an option but doesn't fill the need for an installer.
Not sure why its hasn't been done.
See https://github.com/ldc-developers/ldc/issues/1754.
From the discussions, it seems you still don't see the value
of an installer...backing it with the idea that LDC is for
"developers". I'm a developer myself and I use installers all
the time when on Windows...there are very few people I
personally know who would go for an archive file to set it up
themselves.
So not everyone is like you. The reason why I personally go
for DMD over LDC is convenience (especially when introducing D
to newbies)...even though LDC is more optimized for
performance.
Unless what you guys are doing is an artificial barrier to get
others to not use it.
Guys, all points have been made, there is no wrong and right
here, let's stop arguing over this.
What is needed is someone who thinks it is useful to have an
exe installer and wants to do the work. It cannot be done by
someone who thinks it is not useful, because there are
decisions to be made (like which folder to install it in,
whether to overwrite old or not), that can only be made by
someone who actually cares about it. There is no point in
trying to convince kinke or me.
I'm sure noone will be against uploading the installer exe onto
github release page once it's been made and checked.
-Johan
Johan hits an important nail right on the head here.
While it is possible to design for others who are unlike you,
it's much harder than designing for yourself or those who have
similar values and priorities w.r.t. the thing in question. A lot
of talk about "we (and by we I mean you) should do this thing I
think is important" isn't pushing in the most productive
direction, because
_*_*_{
even if one becomes convinced that there is value in something,
that does not mean one has the relevant understanding necessary
for good design of that thing
}_*_*_
Either the person with the problem works on understanding the
tools to fix the problem, or the person with the tools works on
understanding the problem. When values and "user experience" and
"ease of use" are in play, I think the latter usually gets harder
than normal, because understanding what will be easy or pleasing
for others who are unlike us is not something everyone is good
at.* This shifts the balance towards preferring the former
approach where the person with the problem works towards doing at
least a significant part of the design.** There will always be
other considerations of course, this is just one force out of
many.
This is not to say that developers shouldn't be thoughtful about
their users - they definitely should be - but that doing a good
job of that when the users are unlike the developer is _hard_.
* Perhaps in practice that ability is negatively associated with
a strong sense of personal taste, e.g. great musicians writing
the music _they_ want, not trying to specifically please people;
the magic isn't that they understand other people, it's that
their particular tastes resonate with others strongly. Maybe
truly great mass-market businesses come from people who both have
that magic _and_ a strong ability to experience their work from
other's perspectives, the combination being rare and the ability
to integrate the two effectively being even rarer (Steve Jobs
comes to mind).
** Design and implementation often don't separate very cleanly in
practice, so this probably means implementing it too, at least to
proof-of-concept quality.
Re: Computing the next SemVer for dlang packages with dsemver
On Thursday, 22 October 2020 at 08:59:18 UTC, Robert burner Schadek wrote: I should stop ranting now. Not at all, I love it. Nice project.
Re: Computing the next SemVer for dlang packages with dsemver
On Wednesday, 21 October 2020 at 17:58:53 UTC, Sönke Ludwig wrote: The thing is just that I don't think it is possible to find a set of rules that always work. There will always be something that should "obviously" be flagged as a breaking change and something that is extremely annoying to be detected as such (forcing a major version increment). True, but if we can get 90% of the way there by a tool we would be a lot better of then where we are today. You should always be able to increment the SemVer by hand. But as some kind of warning/hint and with some kind of integration into the version tagging process (maybe forcing a manual version release on the registry after warnings come up) it could definitely be really nice. I'm thinking of a service that gives you a batch that shows you next SemVer of the master branch, as a start.
Re: Computing the next SemVer for dlang packages with dsemver
On Wednesday, 21 October 2020 at 17:55:00 UTC, Sönke Ludwig wrote: 0.x.y vs. 1+.x.y is about the development process/state. Quite often a design is not yet fully fleshed out in the beginning and there are many incremental changes to the API. If 0.x.y didn't exist, that would simply mean that either the project gets more or less stuck with the initial (bad) design, or that it quickly increments major versions, effectively providing no more stability as in the 0.x.y case. I think that is the one mistake SemVer does. 0.x.y is just one big loophole. After the 1.x.y release an breaking api change requires a major version increment. The way it should be. Stability or unstable is only mentioned in the 0.x.y definitions. You are not stuck on a bad design, break the api, improve the api, increment the major version number. If you break the api in an 0.x.y version the hard part does not change. In both instances the users have to update their usage. In know in theory 0.x.y should be considered unstable. But by amount of 0.x.y we have you pretty much can't get anything done in D if you only use stable packages. The loophole has become the normal case. So what can we do, I see two major options: 1. we can live on the edge and use unstable packages and have no meaning in the SemVer number 2. we can acknowledge that most of them are stable, put a 1. in front and ignore the 0.x.y part of the SemVer definition and have the SemVer mean something dsemver does 2. And true there might be cases where dsemver does not increment the number correctly, but you can always increment by hand. Also if your api is not stable after your 1.x.y release and you break everything in 2.x.y, so what. Your users are also annoyed when you break your api from 0.1.x to 0.1.1. Only difference is they could have seen in coming by looking at the SemVer. I should stop ranting now.
