Transitioning to the new Release Process

foobar foo at bar.com
Tue Jan 15 06:05:42 PST 2013


On Monday, 14 January 2013 at 10:33:56 UTC, mist wrote:
> On Saturday, 12 January 2013 at 12:30:05 UTC, Johannes Pfau 
> wrote:
>> Am Fri, 11 Jan 2013 18:54:12 +0100
>> schrieb "mist" <none at none.none>:
>>
>>> Short comment about cherry pick - it is only bad in sense 
>>> that it
>>> creates separate untrackable commit with same content, which 
>>> may
>>> easily result in merging issues. If there is only one-way
>>> direction for commit transitioning ( stuff goes from master to
>>> staging and LTS and never goes back ) there is nothing 
>>> inherently
>>> bad about cherry pick.
>>
>> Having multiple commit ids for the same commit is also 
>> annoying. For
>> example if someone bisected a regression and you want to 
>> revert a commit
>> you have to figure out the commit id of the cherry picked 
>> commits.
>>
>
> AFAIK reverts are content-based, so knowing any one commit id 
> is enough. It is annoying mostly when comparison happens 
> between two branches with those commits.
>
>>> Much more important point is that
>>> it complicates development process for newcomers without any
>>> reasonable benefit. And if we still gonna push for success as 
>>> an
>>> open-source project, being easy understandable by an outsider 
>>> is
>>> as important as a clear release process.
>> The rule is quite simple and easy to understand though:
>> regression fix -> version branch
>> bug fix -> staging
>> enhancement -> master
>
> Ye, it is easy.. except you need to actually check out wiki 
> page to be aware about it. At the very least we need relevant 
> excerpts for outer devs separated to one small wiki page and 
> set links to this page in github marked with big "NB:".
>
> I don't have a reason to argue about the rest.

The default is /master/ so any new dev unfamiliar with the 
process will just get his stuff delayed by one release which 
provides extra safety if you think about it. There is no _need_ 
to read the wiki as the process will work just fine without it. 
it'll just default too the longer, safer option.
I really see no point in arguing this "it complicates the 
process" point any further.


More information about the Digitalmars-d mailing list