View mode: basic / threaded / horizontal-split · Log in · Help
December 18, 2012
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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...
9 10 11 12 13 14 15 16 17
Top | Discussion index | About this forum | D home