December 19, 2012
On 12/19/12 1:45 PM, H. S. Teoh wrote:
> 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.

I was hoping for more consensus to build in this thread. Right now it seems there's still quite a bit of controversy about what the best way to go is.

Andrei


December 19, 2012
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei Alexandrescu wrote:
>
> I was hoping for more consensus to build in this thread. Right now it seems there's still quite a bit of controversy about what the best way to go is.
>
> Andrei

We need to list out all the main points of contention and pick away at them until there's none left

I suspect that some of it may be more of a misunderstanding than real contention, but no doubt a few key points are in contention.

In terms of "core devs", I know about Walter and Andrei, so who else is there that has yet to give us any input?

--rt
December 19, 2012
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei Alexandrescu wrote:
> I was hoping for more consensus to build in this thread. Right now it seems there's still quite a bit of controversy about what the best way to go is.
>

I'm afraid a lot of discussions we see right now are plain useless because overengineered. This shouldn't prevent us from switching some more basics things, like the git workflow and see how it work.

This process need some actual practical use for the reflection to go forward, as it has gone way too far in the stratosphere.
December 19, 2012
On Wednesday, 19 December 2012 at 19:26:48 UTC, deadalnix wrote:
> On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei Alexandrescu wrote:
>> I was hoping for more consensus to build in this thread. Right now it seems there's still quite a bit of controversy about what the best way to go is.
>>
>
> I'm afraid a lot of discussions we see right now are plain useless because overengineered. This shouldn't prevent us from switching some more basics things, like the git workflow and see how it work.
>
> This process need some actual practical use for the reflection to go forward, as it has gone way too far in the stratosphere.

Yes, overengineering is pointless, and doing something basic is better than doing nothing at all, and knowing what will work and what won't and what the challenges are means that we have to try something out or we'll never learn anything.

There are some main points that I think everyone agrees with that could be implemented immediately.

Do we all agree that MASTER becomes the "Dev" branch?

Do we all agree that we need a "testing" (aka staging) branch?

Do we all agree that we need a "stable" branch?

--rt
December 19, 2012
On Wed, Dec 19, 2012 at 02:01:57PM -0500, Andrei Alexandrescu wrote:
> On 12/19/12 1:45 PM, H. S. Teoh wrote:
> >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.
> 
> I was hoping for more consensus to build in this thread. Right now it seems there's still quite a bit of controversy about what the best way to go is.
[...]

I think we need more input from the core devs before any further discussions make sense. Like deadalnix said, we've gone way overboard with the over-engineering; can we at least get the core devs to evaluate the most basic tenets of the proposal first?

Others can correct me if I'm wrong, but the main points as I understand them are:

- Continue using master for development, as before.

- New features will be developed in their own dedicated branches
  (branched from master), NOT on master directly. When the new feature
  is deemed ready, by some criterion to be decided on, then it's merged
  into master.

- At some point in the process, perhaps after a release is made from
  staging (see below), the new changes in master are folded into the
  staging branch (we can argue about the exact name of this later).

- The intent of staging is to test new features and possibly breaking
  changes by a wider audience before the official release. It is to be
  used by people who want bleeding-edge features and can live with
  existing code breaking once in a while.

- Staging only receives bugfixes and no new features until it's deemed
  release-ready. It may receive breaking changes if a particular feature
  is deemed unsuitable in its present form and needs to be revised.
  (Said changes are also applied to master, of course.) This is where
  new features are refined from their initial design to their final
  form.

- Once staging is release-ready, a release branch is made from staging,
  then the latest stuff from master is folded into staging.

- A release branch is used for applying critical bugfixes and
  showstopper fixes after a release is made. It does not receive
  low-priority bug fixes, and certainly no new features and no breaking
  changes.

I deliberately left out things like version numbering and timelines, etc., as those are just bikeshedding. The exact criteria under which master is folded into staging, and staging is deemed release-ready, are intentionally left vague. We need the core devs to evaluate whether these high-level steps in the process are actually workable first, before we even think about timelines, version numberings, and merging/branching criteria.


T

-- 
All problems are easy in retrospect.
December 19, 2012
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
> On Wednesday, 19 December 2012 at 19:26:48 UTC, deadalnix wrote:
>> On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei Alexandrescu wrote:
>>> I was hoping for more consensus to build in this thread. Right now it seems there's still quite a bit of controversy about what the best way to go is.
>>>
>>
>> I'm afraid a lot of discussions we see right now are plain useless because overengineered. This shouldn't prevent us from switching some more basics things, like the git workflow and see how it work.
>>
>> This process need some actual practical use for the reflection to go forward, as it has gone way too far in the stratosphere.
>
> Yes, overengineering is pointless, and doing something basic is better than doing nothing at all, and knowing what will work and what won't and what the challenges are means that we have to try something out or we'll never learn anything.
>
> There are some main points that I think everyone agrees with that could be implemented immediately.
>
> Do we all agree that MASTER becomes the "Dev" branch?
>

Yes

> Do we all agree that we need a "testing" (aka staging) branch?
>

Yes

> Do we all agree that we need a "stable" branch?
>

No. Stable isn't a boolean criteria. You'll find different degree of stability going from not so stable (dev version) to very stable (dead project).

The wiki already mention a process with a branch per version of the software.
December 19, 2012
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>
>> Do we all agree that we need a "stable" branch?
>>
>
> No. Stable isn't a boolean criteria. You'll find different degree of stability going from not so stable (dev version) to very stable (dead project).
>
> The wiki already mention a process with a branch per version of the software.

Let's generalize this point for the sake of reaching consensus - we need _at least one_ "stable" branch which is separate from "staging". We are still conflicted as to what should be the maximum amount. For the record, I'm with the camp advocating at most a fixed amount countable on one hand. That's an O(1) with a very small constant as opposed to the O(n) suggestion by Andrei. I hope Andrei appreciates the order of efficiency here.
December 19, 2012
On 12/19/12 4:23 PM, foobar wrote:
> On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
>> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>>
>>> Do we all agree that we need a "stable" branch?
>>>
>>
>> No. Stable isn't a boolean criteria. You'll find different degree of
>> stability going from not so stable (dev version) to very stable (dead
>> project).
>>
>> The wiki already mention a process with a branch per version of the
>> software.
>
> Let's generalize this point for the sake of reaching consensus - we need
> _at least one_ "stable" branch which is separate from "staging". We are
> still conflicted as to what should be the maximum amount. For the
> record, I'm with the camp advocating at most a fixed amount countable on
> one hand. That's an O(1) with a very small constant as opposed to the
> O(n) suggestion by Andrei. I hope Andrei appreciates the order of
> efficiency here.

I agree with one "stable" branch.

Andrei
December 19, 2012
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei Alexandrescu wrote:
> On 12/19/12 4:23 PM, foobar wrote:
>> On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
>>> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>>>
>>>> Do we all agree that we need a "stable" branch?
>>>>
>>>
>>> No. Stable isn't a boolean criteria. You'll find different degree of
>>> stability going from not so stable (dev version) to very stable (dead
>>> project).
>>>
>>> The wiki already mention a process with a branch per version of the
>>> software.
>>
>> Let's generalize this point for the sake of reaching consensus - we need
>> _at least one_ "stable" branch which is separate from "staging". We are
>> still conflicted as to what should be the maximum amount. For the
>> record, I'm with the camp advocating at most a fixed amount countable on
>> one hand. That's an O(1) with a very small constant as opposed to the
>> O(n) suggestion by Andrei. I hope Andrei appreciates the order of
>> efficiency here.
>
> I agree with one "stable" branch.
>

This does conflict with the requirement you gave before about being able to support anything, as previous stable version cannot be revised.

Or does stable here mean supported ? (which means we still have branch per version, but only one version is supported)
December 19, 2012
On 12/19/12 4:40 PM, deadalnix wrote:
> On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei Alexandrescu wrote:
>> On 12/19/12 4:23 PM, foobar wrote:
>>> On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
>>>> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>>>>
>>>>> Do we all agree that we need a "stable" branch?
>>>>>
>>>>
>>>> No. Stable isn't a boolean criteria. You'll find different degree of
>>>> stability going from not so stable (dev version) to very stable (dead
>>>> project).
>>>>
>>>> The wiki already mention a process with a branch per version of the
>>>> software.
>>>
>>> Let's generalize this point for the sake of reaching consensus - we need
>>> _at least one_ "stable" branch which is separate from "staging". We are
>>> still conflicted as to what should be the maximum amount. For the
>>> record, I'm with the camp advocating at most a fixed amount countable on
>>> one hand. That's an O(1) with a very small constant as opposed to the
>>> O(n) suggestion by Andrei. I hope Andrei appreciates the order of
>>> efficiency here.
>>
>> I agree with one "stable" branch.
>>
>
> This does conflict with the requirement you gave before about being able
> to support anything, as previous stable version cannot be revised.
>
> Or does stable here mean supported ? (which means we still have branch
> per version, but only one version is supported)

Walter needs to chime in about that. One possibility is to continue using tags for marking releases, and then branch for the few important releases that we want to patch.


Andrei