December 16, 2012
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
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
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
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
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
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
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
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
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
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.