View mode: basic / threaded / horizontal-split · Log in · Help
December 16, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 15:05:58 UTC, Andrei Alexandrescu 
wrote:
> On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
>> On 12/15/2012 09:39 PM, deadalnix wrote:
>>> Can we drop the LTS name ? It reminds me of ubuntu, and I 
>>> clearly hope
>>> that
>>> people promoting that idea don't plan to reproduce ubuntu's 
>>> scheme :
>>> - it is not suitable for a programming language (as stated 3 
>>> time now,
>>> so just
>>> read before why I won't repeat it).
>>> - ubuntu is notoriously unstable.
>>
>> Call them "stable release cycles" if you like, which is what 
>> they are
>> intended to be.
>
> 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

This sounds to me like a bad idea. And indeed, I haven't heard of 
any other project doing this.

If you do so, you'll quickly stop maintaining the older branches 
(especially when the corporate users pay for their specific 
developments), forcing users to hop to newer branches, with the 
possibility of breaking changes, so it's no different than 
today's situation.

If they really want specific developments, let them have their 
own branch and not interfere with a community driven process. In 
fact, I may sound harsh and a bit extreme, but I think paying 
users should have a priority to bugfixes and that's it, not on 
the development of the language itself, as they will attempt to 
rush half baked features.

I do think a bleeding edge branch and one or two stable branches 
(let's say one per year for the last two years) is good enough. 
And one branch for the paying user, which will merge to the 
bleeding edge if its specific developments prove worthwhile. But 
as soon as there are more than one paying user, it will 
instantaneously become impractical, so that really, they should 
just be limited to bugfixes.

BTW, will they share with the community their own developments ?
December 16, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
> On Sunday, 16 December 2012 at 15:05:58 UTC, Andrei 
> Alexandrescu wrote:
>> On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
>>> On 12/15/2012 09:39 PM, deadalnix wrote:
>>>> Can we drop the LTS name ? It reminds me of ubuntu, and I 
>>>> clearly hope
>>>> that
>>>> people promoting that idea don't plan to reproduce ubuntu's 
>>>> scheme :
>>>> - it is not suitable for a programming language (as stated 3 
>>>> time now,
>>>> so just
>>>> read before why I won't repeat it).
>>>> - ubuntu is notoriously unstable.
>>>
>>> Call them "stable release cycles" if you like, which is what 
>>> they are
>>> intended to be.
>>
>> 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
>
> This sounds to me like a bad idea. And indeed, I haven't heard 
> of any other project doing this.
>
> If you do so, you'll quickly stop maintaining the older 
> branches (especially when the corporate users pay for their 
> specific developments), forcing users to hop to newer branches, 
> with the possibility of breaking changes, so it's no different 
> than today's situation.
>
> If they really want specific developments, let them have their 
> own branch and not interfere with a community driven process. 
> In fact, I may sound harsh and a bit extreme, but I think 
> paying users should have a priority to bugfixes and that's it, 
> not on the development of the language itself, as they will 
> attempt to rush half baked features.
>
> I do think a bleeding edge branch and one or two stable 
> branches (let's say one per year for the last two years) is 
> good enough. And one branch for the paying user, which will 
> merge to the bleeding edge if its specific developments prove 
> worthwhile. But as soon as there are more than one paying user, 
> it will instantaneously become impractical, so that really, 
> they should just be limited to bugfixes.
>
> BTW, will they share with the community their own developments ?

Actually, it's pretty much what's written in the wiki.
http://wiki.dlang.org/Release_Process#Release_Schedule
December 16, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
> This sounds to me like a bad idea. And indeed, I haven't heard 
> of any other project doing this.

Having release branches is a common practice for many open source 
projects. For example, KDE creates a branch per minor release, 
with patch releases being made off that branch. LLVM also has a 
branch for each release.

David
December 16, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 20:08:11 UTC, Jacob Carlborg wrote:
> On 2012-12-16 20:04, Jesse Phillips wrote:
>
>> I see it unreasonable to maintain every release. If we need to 
>> make a
>> special "maintenance" release then we directly handle the 
>> issue being
>> requested instead of providing every fix applicable.
>
> We could say that we support X number of older releases.

That was my Y.

A patch should be created off the oldest supported version. If Y 
is 5 then that means checking 5 releases to decided where to 
create the patch from. The current suggestion makes Y at most 3 
and generally 2.

What is being requested is to back port a patch for customer 
using version Z, even if Z is 2.34. It is a special case and the 
driving force could be any number of reasons. The age is not 
really important, but the point is the community officially 
dropped support but someone made a compelling argument to bring 
that support back.
December 16, 2012
Re: Next focus: PROCESS
On Sunday, December 16, 2012 11:23:57 Andrei Alexandrescu wrote:
> Right now we're using a tagging system for releases, implying releases
> are just snapshots of a continuum. But what we need is e.g. to be able
> to patch 2.065 to fix a bug for a client who can't upgrade right now.
> That means one branch per release.

Well, you can still do that. You just create a branch from the tag when you 
need a branch. You don't have to branch from the latest. You can branch from 
any point on the tree, and tags provide a good marker for points to branch if 
you need to.

Then the official release is still clearly tagged, but you can have branches 
based off it when you need it. It also avoids some minor overhead when patching 
releases is rare. My main concern though would be that the actual release 
needs to be clearly marked separately from any patches, so it pretty much 
requires a tag regardless of what you do with branches.

What I would have expected that we do (though I haven't read through most of 
this thread or the wiki yet, so I don't know what's being proposed) would be 
to branch when we do beta, and that branch would be what would ultimately end 
up where we release from, with a tag on the commit which was the actual 
release. If further commits were made for specific clients after the release, 
then either you'd make a branch from that which was specific to that client, or 
you'd put them on the same branch, where'd they'd be after the tag for the 
release and wouldn't affect it.

- Jonathan M Davis
December 17, 2012
Re: Next focus: PROCESS
On Sun, Dec 16, 2012 at 11:43:12PM +0100, David Nadlinger wrote:
> On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
> >This sounds to me like a bad idea. And indeed, I haven't heard of
> >any other project doing this.
> 
> Having release branches is a common practice for many open source
> projects. For example, KDE creates a branch per minor release, with
> patch releases being made off that branch. LLVM also has a branch
> for each release.
[...]

Not just open source projects; at my day job, we do this as well.
Development continues on the main branch, and releases are branched off
this main branch at various point. We don't release immediately after
branching, but run development in parallel for a period of time until
the code to be released is well-tested and stabilized. Then a release is
made.

After a release is made, critical bugfixes and major issues are still
being made to the release branch, and patch releases are issued
periodically from the release branch. Sometimes we go up to two
different release branches receiving bugfixes before the older release
is phased out.

Bugfixes made to the release branches are propagated to the development
branch where applicable. Usually, if the corresponding piece of code
hasn't changed much, the same bug exists in both places and generally
the same fix applies to both of them. Usually, if the code has diverged
significantly, the bug doesn't exist in the new code and the fix can
just remain in the release branch. (Sometimes two different fixes are
needed for the same bug 'cos the code has diverged a lot, but then it
can be treated as two separate bug fixes.)

Furthermore, sometimes a critical bug is found in the release branch but
the fix is already in the development branch. In that case, we backport
the fix from the dev branch, which may sometimes require significant
changes in order to account for the code divergence between the two
branches. Or if even that is insufficient, we have to make a fix
specific to the release branch.

Anyway, I'm saying all this to point out that we should not get too
worked up about the exact details of how all these things work; in
practice, things will always be far more complicated than the idealized
model of the release process that we put on paper. Let's just
concentrate on the most salient points of it -- what branches there are,
when we use them, what is necessary to port bugfixes across them, etc.,
and leave the details to the actual people doing the work. Trying to
dictate everything down to the fine points is a waste of time, because
the core devs probably aren't going to follow it anyway.


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine
December 17, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 22:43:13 UTC, David Nadlinger 
wrote:
> On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
>> This sounds to me like a bad idea. And indeed, I haven't heard 
>> of any other project doing this.
>
> Having release branches is a common practice for many open 
> source projects. For example, KDE creates a branch per minor 
> release, with patch releases being made off that branch. LLVM 
> also has a branch for each release.
>
> David

This can only work if there are very few releases, else one has 
to patch all the branches since a bug has been discovered. If you 
release once per month, you potentially have to patch 10 or 20 
branches.
December 17, 2012
Re: Next focus: PROCESS
On Monday, 17 December 2012 at 05:29:23 UTC, SomeDude wrote:
> On Sunday, 16 December 2012 at 22:43:13 UTC, David Nadlinger 
> wrote:
>> On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
>>> This sounds to me like a bad idea. And indeed, I haven't 
>>> heard of any other project doing this.
>>
>> Having release branches is a common practice for many open 
>> source projects. For example, KDE creates a branch per minor 
>> release, with patch releases being made off that branch. LLVM 
>> also has a branch for each release.
>>
>> David
>
> This can only work if there are very few releases, else one has 
> to patch all the branches since a bug has been discovered. If 
> you release once per month, you potentially have to patch 10 or 
> 20 branches.

This is exactly to handle this kind of grunt work that computer 
and software were invented.
December 17, 2012
Re: Next focus: PROCESS
On Monday, 17 December 2012 at 07:04:29 UTC, deadalnix wrote:

> This is exactly to handle this kind of grunt work that computer 
> and software were invented.

Yep, and why Git handles merging so well. But it doesn't know 
which branches you are merging into until you tell it. So you can 
go ahead and write the program to do that for you.
December 17, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 22:43:13 UTC, David Nadlinger 
wrote:
> On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
>> This sounds to me like a bad idea. And indeed, I haven't heard 
>> of any other project doing this.
>
> Having release branches is a common practice for many open 
> source projects. For example, KDE creates a branch per minor 
> release, with patch releases being made off that branch. LLVM 
> also has a branch for each release.
>
> David

Huh?
Both LLVM and KDE are developed on *subversion* and as such their 
work-flows are not applicable. Not to mention that KDE is vastly 
different in concept and goals than a programming language.

Subversion is conceptually very different from git and its model 
imposes practical restrictions that are not relevant for git, 
mostly with regards to branches, merging, etc. Actions which are 
first class and trivial to accomplish in git. This is analogous 
to designing highways based on the speed properties of bicycles.
7 8 9 10 11 12 13 14 15
Top | Discussion index | About this forum | D home