March 07, 2018
On Wed, Mar 07, 2018 at 03:58:38PM +1300, rikki cattermole via Digitalmars-d-announce wrote:
> On 07/03/2018 2:54 PM, psychoticRabbit wrote:
> > On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:
> > > 
> > > Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us?
> > 
> > That's the day I stop using D.
> > 
> > I do not, and will not, use dub. Full stop.
> > 
> > Same goes for Rust ;-)
> 
> Under such arrangement nobody is forcing you to use dub.
> We wouldn't break distribution or usage of dmd just because of
> changing a make file to dub. That's just silly.

It will force everyone who compiles dmd from source to use dub. It's not the end of the world, but I for one will not be too happy about it. Not to mention, it will introduce bootstrapping issues to Phobos, since dub itself depends on Phobos (again, solvable, but can be a potential source of trouble).


T

-- 
Don't get stuck in a closet---wear yourself out.
March 07, 2018
Am 07.03.2018 um 13:57 schrieb Paolo Invernizzi:
> On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote:
> 
>> Well, for all of the recent releases we made sure that there was no breakage for new compiler versions. This release was an exception, because I didn't manage to put out the fixed release in time. The plan is to have all future releases go back to the normal mode where the new compiler version always works.
>>
>> Since std.experimental isn't involved from now on, it shouldn't even be necessary anymore to put out new vibe.d releases for new DMD versions, because DMD/Phobos already checks for regressions against vibe.d and all breaking changes should simply result in a deprecation warning.
> 
> That's fine, thanks.
> 
>> As for the versioning scheme, currently almost all new releases have some small breaking change or deprecation. If I'd use the "minor" version for that, then there would be no way to signal that a release makes broad and more disruptive changes, such as the 0.8.0 release. But all of this will change, as the remaining parts get pushed to separate repositories one-by-one, with their own version starting at 1.0.0.
> 
> I understand your reasoning, but there's value in being able to just rapidly fix something with a new release, or just port some master bug-fixes into a released version branch.
> 
> DMD is experiencing a very enjoyable release process of patch versions, thanks to Martin and the team.
> 
> It your concern is only related to the best way to inform the users about a broad and disruptive change in vibe-d, I suggest to simply use the usual channels for that, change logs and announce forum.
> 
> My impression is that there's a lot of value in using patch for patch, instead of using patch for development, also in a zero major, so I maybe you should consider that change, or at least, investigate a little about that opportunity.
> 
> /Paolo

But why wouldn't it be possible to make a quick bugfix release with the current scheme? It has happened in the past. Granted, if a 0.8.5-beta.1 is already tagged, then using 0.8.5 for a quick intermediate release would be bad, but at that point the beta could likely also be turned into a full release pretty quickly.

But the point is that the development mode is currently still happening in a linear fashion. Starting to have (a) stable branch(es) with additional point releases would increase the overhead to a point where there wouldn't be any meaningful progress anymore, at least at this time.

Then there is the fact that 0.8.0 was developed in a parallel branch for quite a while. If the minor version would have been used to denote regular small updates, it would not have been possible to tag alpha/beta releases on the 0.8.x branch at all.

March 07, 2018
On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:

>
> It will force everyone who compiles dmd from source to use dub. It's not the end of the world, but I for one will not be too happy about it.

IMO, much better than forcing everyone to compile with make, which I'm not too happy about :-)
March 07, 2018
On Wednesday, 7 March 2018 at 14:53:09 UTC, Sönke Ludwig wrote:

> But why wouldn't it be possible to make a quick bugfix release with the current scheme? It has happened in the past. Granted, if a 0.8.5-beta.1 is already tagged, then using 0.8.5 for a quick intermediate release would be bad, but at that point the beta could likely also be turned into a full release pretty quickly.

Well, I don't know why, but quick is more than 30 days right now using the current release procedure...

https://github.com/vibe-d/vibe.d/issues/2058
https://github.com/vibe-d/vibe.d/releases

Anyway, never mind!

/Paolo
March 07, 2018
Am 07.03.2018 um 17:01 schrieb Paolo Invernizzi:
> On Wednesday, 7 March 2018 at 14:53:09 UTC, Sönke Ludwig wrote:
> 
>> But why wouldn't it be possible to make a quick bugfix release with the current scheme? It has happened in the past. Granted, if a 0.8.5-beta.1 is already tagged, then using 0.8.5 for a quick intermediate release would be bad, but at that point the beta could likely also be turned into a full release pretty quickly.
> 
> Well, I don't know why, but quick is more than 30 days right now using the current release procedure...
> 
> https://github.com/vibe-d/vibe.d/issues/2058
> https://github.com/vibe-d/vibe.d/releases
> 
> Anyway, never mind!
> 
> /Paolo

What I mean are releases like these:

https://vibed.org/blog/posts/vibe-release-0.7.11 (3 days)
https://vibed.org/blog/posts/vibe-release-0.7.28 (16 days)

There are also releases such as 0.7.29 that actually got branched out and was stabilized while 0.7.30 was already pushed further along on master.

But such releases were only done if really necessary, because a release, despite many things being automated, always has quite some overhead, just like maintaining parallel branches has. Depending on the work force and the general development speed that may be okay, but currently development time unfortunately is a premium.
March 07, 2018
On Wed, Mar 07, 2018 at 02:53:17PM +0000, Mike Parker via Digitalmars-d-announce wrote:
> On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:
> > It will force everyone who compiles dmd from source to use dub. It's not the end of the world, but I for one will not be too happy about it.
> 
> IMO, much better than forcing everyone to compile with make, which I'm not too happy about :-)

Touché. :-D  The good thing is that make is pretty much guaranteed to exist in all OS installations (except Windows perhaps? But pretty much anywhere a compiler toolchain is installed), whereas dub isn't.

Seriously, I would be much happier with a D build tool. Dub is not a bad package manager, though it could be better, but IMO it does a poor job at being a general build system.  If it were only made more configurable and less insistent about everything being required to be done its way or the highway, having Phobos distributed as a dub package wouldn't be so bad.

But who knows. Maybe being forced to use dub to build Phobos would finally provide the motivation for people to improve dub as a build tool. But AIUI there are some fundamental design assumptions built into dub that basically makes it impossible to fix some of these issues without pretty much rewriting it from ground up.  Because of this, I have not found myself particularly inclined to actually look at its code.


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.
March 07, 2018
On 3/7/18 12:02 PM, H. S. Teoh wrote:
> On Wed, Mar 07, 2018 at 02:53:17PM +0000, Mike Parker via Digitalmars-d-announce wrote:
>> On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:
>>> It will force everyone who compiles dmd from source to use dub. It's
>>> not the end of the world, but I for one will not be too happy about
>>> it.
>>
>> IMO, much better than forcing everyone to compile with make, which I'm
>> not too happy about :-)
> 
> Touché. :-D  The good thing is that make is pretty much guaranteed to
> exist in all OS installations (except Windows perhaps? But pretty much
> anywhere a compiler toolchain is installed), whereas dub isn't.

You need a D compiler to build D. So dub is probably there too.

Note that I'm against having phobos being a separate dependency from the compiler, but I'm not against switching to dub for the build.

-Steve
March 08, 2018
On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:
> Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag?

Also this offer still stands
https://forum.dlang.org/post/drcekmxvfszpwifbukzk@forum.dlang.org



March 09, 2018
On 2018-03-08 19:21, Martin Nowak wrote:

> Also this offer still stands
> https://forum.dlang.org/post/drcekmxvfszpwifbukzk@forum.dlang.org

Who will decide if semver can/will be used?

-- 
/Jacob Carlborg
1 2 3 4 5
Next ›   Last »