Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> GIT

tl;dr yes and yes

In an effort to continue productive conversation, let's go off of what
Keith was saying about making a branch suffixed with -SNAPSHOT to denote
the provenance of the changes and lifecycle of said branch.

Let's take the 1.4 series as an example:

1.4.4 has been released. The first person finds some changes that should
be placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would
be created from the 1.4.4 tag.

`git checkout 1.4.4 && git checkout -b 1.4.5-SNAPSHOT; hack; commit; git
push origin 1.4.5-SNAPSHOT`

After which, 1.4.5-SNAPSHOT would contain a certain number of bug-fixes
until it is deemed appropriate to release 1.4.4.

At which point, we would tag off of the 1.4.5-SNAPSHOT branch, merge the
tag into the 1.5 series and through to the 1.6 series and delete the
remote-tracking 1.4.5-SNAPSHOT branch as it now contains no additional
information not contained by the 1.4.5 tag.

On 06/04/2013 10:05 PM, Drew Farris wrote:
> On Tuesday, June 4, 2013, Josh Elser wrote:
>> The thing I don't care for (putting it mildly) is long-running
>> minor-release branches. I'm curious of suggestions that people might have
>> for how to work around this. One possibility would be to be git-tag heavy
>> while being more lax on official apache releases.
>   I think I understand, but I am curious: At what point would we trash the
> minor release branch? For example, would we have trashed 1.4 by now? When
> would we trash the 1.5 branch?
> Also, do we tag from the short-lived branch 1.4.5-SNAPSHOT? When we delete
> the branch, will the tag preserve the history of what happened on that
> branch? E.g all of the commits that took us from 1.4.4 to 1.4.5?