December 18, 2012
On Tuesday, 18 December 2012 at 22:37:10 UTC, SomeDude wrote:
> On Tuesday, 18 December 2012 at 20:55:34 UTC, Joseph Rushton Wakeling wrote:
>> On 12/18/2012 09:48 PM, SomeDude wrote:
>>> And it's not the same at all as creating one branch every month.
>>
>> But why would you do that?  The general discussion seems to have been around the idea of 1 or 2 stable releases per year, 1 every 3 months max.
>
> THat's what I understood from Andrei's post:
>
>> Just one tidbit of information: I talked to Walter and we want to build into the process the ability to modify any particular release. (One possibility is to do so as part of paid support for large corporate users.) That means there needs to be one branch per release.
>>
>> Andrei
>
> Maybe I misunderstood him, I don't know.

He seemed to imply that, but to me it makes little sense to support older versions of a stable release. The support comes from the latest stable bug fix update, and you normally don't bother propagating a bug fix any further down stream. The best you may do, is after a new release is made, continue supporting the latest older release for a limited period of time until the newest release is considered completely free of any major bugs.

If there's a code breaking release, I can see the previous older stable version being supported for a fairly long period of time.

--rt
December 19, 2012
On Tuesday, 18 December 2012 at 20:55:34 UTC, Joseph Rushton Wakeling wrote:
> On 12/18/2012 09:48 PM, SomeDude wrote:
>> And it's not the same at all as creating one branch every month.
>
> But why would you do that?  The general discussion seems to have been around the idea of 1 or 2 stable releases per year, 1 every 3 months max.

This is probably too slow for revision and too fast for new versions.

This is yet another point where the distro process don't apply to us : distro update a given version on a per package basis, which make absolute no sense for us.
December 19, 2012
On 12/19/2012 01:00 AM, deadalnix wrote:
> This is probably too slow for revision and too fast for new versions.

I'm not counting minor-point bugfix updates as a "release" in this context, as I doubt you'd have a separate branch for those.

> This is yet another point where the distro process don't apply to us : distro
> update a given version on a per package basis, which make absolute no sense for us.

....?  I don't think this has any relation to anything that anyone has proposed.

December 19, 2012
On Wednesday, 19 December 2012 at 01:08:28 UTC, Joseph Rushton Wakeling wrote:
> On 12/19/2012 01:00 AM, deadalnix wrote:
>> This is probably too slow for revision and too fast for new versions.
>
> I'm not counting minor-point bugfix updates as a "release" in this context, as I doubt you'd have a separate branch for those.
>

I don't see how they aren't release. They are released. But they have branches, they are tags. Each time you package the software to put it in download somewhere for users to use, you do a release.

I you want to talk about branch or versions talk about branch or versions, not release please.
December 19, 2012
On 12/19/2012 02:22 AM, deadalnix wrote:
> I don't see how they aren't release. They are released. But they have branches,
> they are tags. Each time you package the software to put it in download
> somewhere for users to use, you do a release.
>
> I you want to talk about branch or versions talk about branch or versions, not
> release please.

OK, let me rephrase it.  I doubt that it makes sense to have a separate branch for minor point releases (i.e. going from N.x.y --> N.x.y+1, a bugfix release).

You'd have an N.x branch and you'd tag the .y minor point releases.

I don't think this is in contradiction with Andrei's intentions.
December 19, 2012
On Wednesday, 19 December 2012 at 01:38:16 UTC, Joseph Rushton Wakeling wrote:
> On 12/19/2012 02:22 AM, deadalnix wrote:
>> I don't see how they aren't release. They are released. But they have branches,
>> they are tags. Each time you package the software to put it in download
>> somewhere for users to use, you do a release.
>>
>> I you want to talk about branch or versions talk about branch or versions, not
>> release please.
>
> OK, let me rephrase it.  I doubt that it makes sense to have a separate branch for minor point releases (i.e. going from N.x.y --> N.x.y+1, a bugfix release).
>
> You'd have an N.x branch and you'd tag the .y minor point releases.
>
> I don't think this is in contradiction with Andrei's intentions.

No indeed. I think that this way make sense. But I'm afraid that releasing a new version (note version, not revision) every 6 month or so will lead to an important number of version to maintain simultaneously if we want to ensure some stability.

I think the smart move here is to release new feature less often, but to release more at once, and at the same time go fast on bug fixes.

I frankly more worried about the fact that D has feature that don't integrate nicely with each other right now than by D not having enough features.
December 19, 2012
On Wednesday, 19 December 2012 at 01:48:49 UTC, deadalnix wrote:
> I think the smart move here is to release new feature less often, but to release more at once, and at the same time go fast on bug fixes.

I'm not a a fan of time line based releases (snapshots), it makes no sense to me at all other than for producing a testing version, and even then I'm not so sure.

Why release a new stable branch every 6 mo's or whatever? Why not release a new stable branch when there's one worth releasing? Why not instead focus on releasing "revisions" (bug fixes) instead, up until there's enough of something new worth releasing as a package. New stable releases, should be major version number increments and they should not happen very often. Bug fixes should happen much more often, and if they are released as new branches, then the old ones should not get support, as it's pointless, that's what the most recent stable release branch provides. I can see us supporting a previous major release version, but not any of the minor bug fix increments that appeared along the way.

Perhaps there is resistance to changing from the current "snapshot" process which tends to produce meaningless buggy/breaking releases, to one that is a "feature" based release.

> I frankly more worried about the fact that D has feature that don't integrate nicely with each other right now than by D not having enough features.

I sure hope everyone can agree with that.

--rt
December 19, 2012
On Wednesday, 19 December 2012 at 06:31:04 UTC, Rob T wrote:
> On Wednesday, 19 December 2012 at 01:48:49 UTC, deadalnix wrote:
>> I think the smart move here is to release new feature less often, but to release more at once, and at the same time go fast on bug fixes.
>
> I'm not a a fan of time line based releases (snapshots), it makes no sense to me at all other than for producing a testing version, and even then I'm not so sure.
>
> Why release a new stable branch every 6 mo's or whatever? Why not release a new stable branch when there's one worth releasing? Why not instead focus on releasing "revisions" (bug fixes) instead, up until there's enough of something new worth releasing as a package. New stable releases, should be major version number increments and they should not happen very often. Bug fixes should happen much more often, and if they are released as new branches, then the old ones should not get support, as it's pointless, that's what the most recent stable release branch provides. I can see us supporting a previous major release version, but not any of the minor bug fix increments that appeared along the way.
>
> Perhaps there is resistance to changing from the current "snapshot" process which tends to produce meaningless buggy/breaking releases, to one that is a "feature" based release.
>

I can't even say if you agree or disagree with what you quote.

If we want to understand each other, it may be nice to start using common vocabulary. In the planned process exposed on the wiki, you'll find no branch called stable (for good reasons).

Nobody talked about doing revisions in branches, it make no sense. Again, you should read what is written in the wiki page.

Nothing is released as new branch. I don't even understand what it is supposed to mean. Thing are released as .zip/.deb/.rpm/.dmg/whatever packages.

Finally, nobody is supposed to support fix, this is the other way around : fix are what you do when a supported version has a bug.
December 19, 2012
On Wednesday, 19 December 2012 at 06:31:04 UTC, Rob T wrote:
> Perhaps there is resistance to changing from the current "snapshot" process which tends to produce meaningless buggy/breaking releases, to one that is a "feature" based release.

I don not see a greater correlation between snapshot releases and buggy/breaking any more than a feature based release being buggy/breaking.

To facilitate feature releases a plan for what/how many features will make a release. I'm not against having these, only against requiring it for a release.

Having it based on "important" or "enough" changes is subjective and the small things can be very important to someone. And even with just bugs, how many make for a good release/revision (we have way to many names that all seem to mean something different to everyone)?

I will agree though, if there isn't anything worth releasing, don't release it. But my threshold for 'worth' is much lower than yours.

I'd also say it has little to do with new "features" as it is about completing features and disruptive bugs. I'd think the supported/stable/lts/somethingsomething would be open to Phobos additions, but I'm not too concerned as things can be changed.
December 19, 2012
On Fri, Dec 14, 2012 at 10:16:45AM -0500, Andrei Alexandrescu wrote:
> On 12/14/12 10:02 AM, H. S. Teoh wrote:
> >A number of us have put up a draft of a proposed release process on the wiki, based on some of the things discussed in this thread.
> >
> >	http://wiki.dlang.org/Release_Process
> 
> Seen it, will give a thorough read today. Thanks!
[...]

Just to follow up, any comments on what's there currently?

I fear that some of us on this thread may be over-engineering the whole thing without input from the core devs who will actually be implementing this process.


T

-- 
My program has no bugs! Only undocumented features...