I think your right if nothing needs to change. IIUC there is a general preference for tags being
pristine with no modifications. So, if a release can go from being worked to a good release then
the Maven system is great. I think the reality is that there will generally be the time required to
wait for a release to bake. If changes are needed then they either need to be applied to the tagged
version or copied and re-tagged (which IMHO is really undesireable).
I think the idea of no changes to tags makes sense. If Maven could handle the process and take into
account the timing and possible re-work that would be awesome. Right now the 1.1.0 release has been
there for the better part of two weeks. I don't think we want to stall development like this in the
future.
If there is a way to address this with m2 that would be great.
Jason Dillon wrote:
Hi Jason,
I agree that we should avoid branching. But I do agree with the 1.1.1
branch. It's a dead-end branch in that it's only used to prepare he
release. Applying last minute fixes and changing version numbers.
Since it's a dead-end branch, once the release if approved
moving/deleting it makes sense.
I would make those changes on the 1.1 branch (or trunk if we were using
that codebase), then release and let Maven make the tag and then update
the versions to the next SNAP.
When moving to m2 we really need to follow the m2 release system, else
the number of changes to poms is going to get out of control and will be
very error prone.
--jason
