December 21, 2012
On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman wrote:
> On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei Alexandrescu wrote:
>>
>> I agree with one "stable" branch.
>>
>> Andrei
>
> Just some food for thought.
>
> In the section about the "Branching model", the wiki currently has a staging branch in addition to the master branch. From what I understand, the idea seems to be to vet a release on staging until it is considered production level and then marked as the release.
>
> Another idea could be to keep the quality of the master branch at a high level so as to be able to branch into a release at any time, directly from master. Before feature branches are merged back into master, their quality is vetted so the quality of master is maintained.
>

I prefer this one. It's simpler, less to memorize. Staging area complicates things. I propose to go for a yearly release of the stable branches with one year support (In the beginning). So development needs to be of super high quality once a year.


> This idea seems similar to what is used for the vibe.d project (http://vibed.org/temp/branch-model-small.png). My apologies if I misunderstood their process.
>
> It looks like Xamarin has been using this process for a while and it seems to be working for them. http://tirania.org/blog/archive/2011/Oct-14.html
>
> Joseph

December 21, 2012
On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman wrote:
> Just some food for thought.
>
> In the section about the "Branching model", the wiki currently has a staging branch in addition to the master branch. From what I understand, the idea seems to be to vet a release on staging until it is considered production level and then marked as the release.
>
> Another idea could be to keep the quality of the master branch at a high level so as to be able to branch into a release at any time, directly from master. Before feature branches are merged back into master, their quality is vetted so the quality of master is maintained.
>
> This idea seems similar to what is used for the vibe.d project (http://vibed.org/temp/branch-model-small.png). My apologies if I misunderstood their process.
>
> It looks like Xamarin has been using this process for a while and it seems to be working for them. http://tirania.org/blog/archive/2011/Oct-14.html
>
> Joseph

Doesn't that just turn master into staging, and turn the feature branches into a diluted and distributed version of master?

If there's no common development branch to work with that integrates the most current features together, then how will such a thing ever be properly tested before going into a high quality common branch?

We also need the ability to stop brand new poorly tested features from making their way into a release, so at some point a common pre-release branch needs to be frozen from receiving any new features so that it can be honed into a high quality product. If you use the master branch for such a thing, then no new features can go into it, so with master frozen, what common branch is available for the devs to merge their new work into?

--rt
December 21, 2012
On Friday, 21 December 2012 at 18:34:12 UTC, Rob T wrote:
> On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman wrote:
>> Just some food for thought.
>>
>> In the section about the "Branching model", the wiki currently has a staging branch in addition to the master branch. From what I understand, the idea seems to be to vet a release on staging until it is considered production level and then marked as the release.
>>
>> Another idea could be to keep the quality of the master branch at a high level so as to be able to branch into a release at any time, directly from master. Before feature branches are merged back into master, their quality is vetted so the quality of master is maintained.
>>
>> This idea seems similar to what is used for the vibe.d project (http://vibed.org/temp/branch-model-small.png). My apologies if I misunderstood their process.
>>
>> It looks like Xamarin has been using this process for a while and it seems to be working for them. http://tirania.org/blog/archive/2011/Oct-14.html
>>
>> Joseph
>
> Doesn't that just turn master into staging, and turn the feature branches into a diluted and distributed version of master?
>
> If there's no common development branch to work with that integrates the most current features together, then how will such a thing ever be properly tested before going into a high quality common branch?
>
> We also need the ability to stop brand new poorly tested features from making their way into a release, so at some point a common pre-release branch needs to be frozen from receiving any new features so that it can be honed into a high quality product. If you use the master branch for such a thing, then no new features can go into it, so with master frozen, what common branch is available for the devs to merge their new work into?
>
> --rt

Precisely.
I think people just don't understand the purpose of these additional branches. The point being - integration.

The general flow of events should be:
1. Developer has cool idea/feature which he explores on a separate private "feature branch"
2. During development of the feature the developer can optionally collaborate with other developers. This can be done either by pulling from other developers' repositories directly or by pushing to a branch on github. Either way, this is an ad hoc "my new feature" branch.
3. First level of integration - feature is complete and is merged into official first level of integration - the "dev" branch (consensus was to use master for that)
4. Feature can than be further refined and _integration bugs_ can be fixed by the general dev team.
5. When the "dev" branch is considered stable enough by the team (exact criteria to be defined later), the changes are merged to the _2nd level of integration_ - the "staging" branch. This allows for a wider audience to test and provide real-world feedback.
6. when the 2nd level of integration is complete, the changes are stable enough to be released and the included features finalized.

Since git provides each developer with their own private copy of the entire repository there is *no need* to define any official processes prior to initial integration. The developers are free to collaborate by using ad hoc branches. The only common sense recommendation I'd give (again, NOT part of the _official process_) is to use meaningful branch names if they are meant to be shared with other people.
7 8 9 10 11 12 13 14 15 16 17
Next ›   Last »