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?
