On Sat, Jun 30, 2012 at 12:47 AM, Andrea Aime
<[email protected]>wrote:
> On Sat, Jun 30, 2012 at 3:59 AM, Justin Deoliveira
> <[email protected]>wrote:
>
>>
>> 1. master - unstable, under active development, equivalent of what was
>> trunk
>> 2. n.x -> stable, under active "stable" developer
>> 3. (n-1).x -> previous stable, being phased out
>>
>> For each stable branch we also maintain a release branch that releases
>> are cut from. These branches are tagged for individual releases. At any
>> given point in time the state of this branch is the latest stable release
>> in that series. My rationale for maintaining a separate release branch is
>> mostly because during releases we modify the actual branch to change
>> version numbers, update README, etc.. Without a release branch we would
>> have to do this on the main stable branch which would mean would have to
>> ask people to "get out of the pool", which we have just recently worked to
>> avoid with a lighter weight release process that involves grabbing a single
>> revision and releasing from it.
>>
>> So basically when doing a release the workflow at a high level is:
>>
>> * checkout the release branch
>> * merge with the parent stable branch up until the revision to be
>> released
>> * update version numbers, etc...
>> * tag
>> * push branch and tag up to canonical
>>
>> An alternative to long lived single release branch would be multiple
>> short lived release branches, one for each release, rel_8.0, rel_8.1,
>> etc... I decided against this mostly because the number of branches in
>> the repository will start to accumulate much faster. Also because I like
>> the idea of having a release branch whose state is always exactly that of
>> the last release.
>>
>> You'll notice that in the above diagram there is no corresponding release
>> branch for master. This is intentional and also differs from how we do
>> things today in that we do sometimes cut
>> betas/milestones/release candidates from the trunk. We could potentially
>> create a release branch for master but i figured that with our new time
>> boxed release model and the stable cycle being shorter than in the past we
>> could probably get by without it.
>>
>
> Makes sense, a few observations and questions.
>
> Master wise, if we want to release a milestone, we just tag the master?
> However this will require a "out of the pool"
> period, even if a small one.
>
Yeah, what it would look like is:
1. everyone out of the pool
2. update version numbers, poms, and readme
3. commit
4. tag
5. push master and tag
6. rechange all version numbers back to snapshot, and revert changes to the
readme
7. commit and push
8. everyone back in the pool
All in all i don't really like this, and would prefer a separate branch for
the release. Especially from an automated release standpoint. More on that
below.
> Branch release wise, that seems to work as well, I agree having a ton of
> little branches on github will
> make using the github GUI hard (especially for newcomers) and will leave
> people wondering why
> in the world we have branches that look like tags.
>
> At the same time the release branch is sort of a technicality, isn't it?
> Is there a way to make it "non advertised"
> on github?
>
Not that i know of.
>
> I'm also considering the new automated release process, may there be
> issues using this branch
> model automation wise?
>
I actually think it makes it cleaner. What I was thinking was the scripts
would do this.
build_release:
1. checkout the release branch
2. merge the release branch with its primary branch up until he specified
release revision
3. create a new branch off of the release branch, this branch will never be
pushed up, its just a local staging area
4. make the changes on the temporary branch for version numbers, etc... and
do the main release build
publish_release:
1. switch to the release branch
2. merge in the temporary release branch, which will be a simple fast
forward merge
3. tag and push
4. delete temporary release branch
The reason I like this approach is that it makes it a bit cleaner when
dealing with cases where the build_release failed, or had to be redone for
any reason. Basically there is no mess of having to revert changes like we
do now.
Anyways, just my thoughts.
Assuming we have automation I guess another possible way is to have the
> script make the changes
> on the stable branch, commit, then commit a revert of those, and then tag
> the specific revision number
> that had the version number changes as the release... convoluted enough?
> :-p
>
Yeah, that could work and more less follows what we do today in that we
delete the tag if it already exists. This really has to be done with care
though. I think a temporary branch is somewhat safer in this regard.
>
> Cheers
> Andrea
>
> --
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
