When did the beta branch switch from '2.065' to 'release' and why?  What's going to happen post 2.065 when it's time for 2.066?  And when 2.065 needs a critical bug fix release?

Per-release branches makes a lot more sense from a patch management standpoint.  It's also meant that the auto-tester hasn't been testing the new 'release' branch because I didn't know it existed or needed testing.

Sigh,
Brad
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 1/23/14, 12:29 PM, Brad Roberts wrote:
> When did the beta branch switch from '2.065' to 'release' and why? What's going to happen post 2.065 when it's time for 2.066?  And when 2.065 needs a critical bug fix release?
>
Yes it did. Once 2.065 is released, the branch will be merged back into master and then deleted. When it's time to prepare 2.066, a new release branch will be created. See http://wiki.dlang.org/Simplified_Release_Process_Proposal for additional information.
> Per-release branches makes a lot more sense from a patch management standpoint.  It's also meant that the auto-tester hasn't been testing the new 'release' branch because I didn't know it existed or needed testing.
>
Please add it.

Thanks,
Andrew
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 1/23/14 9:50 AM, Andrew Edwards wrote:
> On 1/23/14, 12:29 PM, Brad Roberts wrote:
>> When did the beta branch switch from '2.065' to 'release' and why? What's going to happen post
>> 2.065 when it's time for 2.066?  And when 2.065 needs a critical bug fix release?
>>
> Yes it did. Once 2.065 is released, the branch will be merged back into master and then deleted.
> When it's time to prepare 2.066, a new release branch will be created. See
> http://wiki.dlang.org/Simplified_Release_Process_Proposal for additional information.

I don't know who to be mad at here, but this is getting !@#$@@#$ing stupid.

Per-release branches were working fine.  They make it easy to keep adding fixes to after release. They're simple.  They're easy to track.  Etc etc.  They're tried and true for oh so many projects.

Sigh, how many more ways is this release going to suck?

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

I believe zeromq use forks for releases.

On 1/23/2014 10:10 AM, Brad Roberts wrote:
> On 1/23/14 9:50 AM, Andrew Edwards wrote:
>> On 1/23/14, 12:29 PM, Brad Roberts wrote:
>>> When did the beta branch switch from '2.065' to 'release' and why? What's going to happen post
>>> 2.065 when it's time for 2.066?  And when 2.065 needs a critical bug fix release?
>>>
>> Yes it did. Once 2.065 is released, the branch will be merged back into master and then deleted.
>> When it's time to prepare 2.066, a new release branch will be created. See
>> http://wiki.dlang.org/Simplified_Release_Process_Proposal for additional information.
>
> I don't know who to be mad at here, but this is getting !@#$@@#$ing stupid.
>
> Per-release branches were working fine.  They make it easy to keep adding fixes to after release. They're simple.  They're easy to track.  Etc etc.  They're tried and true for oh so many projects.
>
> Sigh, how many more ways is this release going to suck?
>

I agree, I don't know what's wrong with what we had before:

1. All pull requests get merged to master
2. Create 2.065 branch
3. Cherry-pick from master to 2.065 as required
4. Tag 2.065.whatever as releases get done on that branch

Easy, simple. All these other procedures seem like massive over-engineering to me.

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Thu, Jan 23, 2014 at 11:10 AM, Brad Roberts <braddr@puremagic.com> wrote:

> On 1/23/14 9:50 AM, Andrew Edwards wrote:
>
>> On 1/23/14, 12:29 PM, Brad Roberts wrote:
>>
>>> When did the beta branch switch from '2.065' to 'release' and why?
>>> What's going to happen post
>>> 2.065 when it's time for 2.066?  And when 2.065 needs a critical bug fix
>>> release?
>>>
>>>  Yes it did. Once 2.065 is released, the branch will be merged back into
>> master and then deleted.
>> When it's time to prepare 2.066, a new release branch will be created. See
>> http://wiki.dlang.org/Simplified_Release_Process_Proposal for additional
>> information.
>>
>
> I don't know who to be mad at here, but this is getting !@#$@@#$ing stupid.
>
> Per-release branches were working fine.  They make it easy to keep adding
> fixes to after release. They're simple.  They're easy to track.  Etc etc.
>  They're tried and true for oh so many projects.
>
>
Something had to change because the release process wasn't working in practice. Very few people were targeting the right branches or merging changes between branches. I do find tags and temporary working release branches a lot more hygienic and simple but I don't have a strong opinion about that aspect.  The only part I think is important with the simplified process is having contributors always target master and let the release manager take care of pulling bug fixes into the release branch. Any other aspect of how this is implemented isn't terribly important so if you think using release branches help significantly we should probably reintroduce them.


> Sigh, how many more ways is this release going to suck?


I think a little patience is in order for this release.  It's the first release by our first release manager/build master using tools that have never been used prior.


>
>
_______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

On Thu, Jan 23, 2014 at 12:01 PM, Walter Bright <walter@digitalmars.com>wrote:
>
>
> I agree, I don't know what's wrong with what we had before:
>
> 1. All pull requests get merged to master
> 2. Create 2.065 branch
> 3. Cherry-pick from master to 2.065 as required
> 4. Tag 2.065.whatever as releases get done on that branch
>
> Easy, simple. All these other procedures seem like massive over-engineering to me.
>
>
I actually wrote up the simplified proposal to switch the formal process over to almost exactly what you just said (with the non essential difference that release branches are temporary and don't have a version in their name). What we had before[1] specifically forbade cherry-picking and instead relied on all contributors targeting multiple branches with their pull requests (which almost nobody ever did as Andrew pointed out).

If we want to use release branches that stick around forever that's fine. Steps 1 and 3 are all I care about having in any release process.

[1] http://wiki.dlang.org/Development_and_Release_Process

On Thu, Jan 23, 2014 at 8:14 PM, Brad Anderson <eco@gnuk.net> wrote:
> […] relied
> on all contributors targeting multiple branches with their pull requests
> (which almost nobody ever did as Andrew pointed out).

Just to make sure that this does not lead to confusion: Each pull request would obviously still target a single pull request, but if the changes were to end up on release branches, the request would have to target the oldest branch where the fix is applicable.

But yes, even though it doesn't lead to duplicate but logically unrelated commits (such as cherry-picking generates), I'm not sure if it would be feasible to require contributors to be aware of that, as discussed previously.

David

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 01/23/2014 08:03 PM, Brad Anderson wrote:
>
>     Sigh, how many more ways is this release going to suck?
>
>
> I think a little patience is in order for this release.  It's the first release by our first release manager/build master using tools that have never been used prior.
And we're down to ~20min. for release building.

On 1/23/14, 1:10 PM, Brad Roberts wrote:
> Yes it did. Once 2.065 is released, the branch will be merged back into master and then deleted.
>> When it's time to prepare 2.066, a new release branch will be created. See
>> http://wiki.dlang.org/Simplified_Release_Process_Proposal for additional information.
>
> I don't know who to be mad at here, but this is getting !@#$@@#$ing stupid.
I've never had a problem taking responsibility for the decisions I make so you can be mad at me if it makes you feel better.
> Per-release branches were working fine.  They make it easy to keep adding fixes to after release. They're simple.  They're easy to track. Etc etc.  They're tried and true for oh so many projects.
I fail to see how "release" makes it many more difficult but I will concede that keeping the branch around does simplify the process of adding fixes after release.
> Sigh, how many more ways is this release going to suck?
>
I'll reserve my opinion here!
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta