I have discussed this a few times now with individual folks. Can't
remember if we ever discussed it or not. I should add this to the
"releasing" wiki page...
Sure I have thought about it. In fact this is how I used to do
It comes down to the fact that things often go wrong during the actual
releasing (Nexus validations fail, Nexus becomes unavailable, etc). My
approach is really about dealing with these possibilities. To be
honest, most of those problems have gone away now that I use Gradle.
Using the "old approach", in those cases one has to make the
appropriate changes, commit and retag. But you are in a bad position
there is someone has pushed since your original tag. Actually this is
what I used to use that stable branch for. Basically I would release
and tag from stable and commit/push any changes needed to "fix the
release" only to stable initially; that essentially was the isolation.
But its a complex and largely unnecessary step I decided considering in
the 10 or so releases I did using that approach not once ever did
someone push changes after I had started a release. Far easier IMO to
just announce that you are starting a release and ask for folks to hold
Essentially your approach does the tag first, making an assumption that
releasing from that tag will work. You run into probems if the release
process breaks down in anyway that requires commitable changes. On the
otherhand, I tag from a commit I *know* will work.
On Wed 04 Apr 2012 02:21:40 PM CDT, Sanne Grinovero wrote:
Just wondering - did you consider tagging and then using a specific
commit id for the release ?
So you wouldn't need to worry about this, you personally pick the
commit and don't care for subsequent commits.
On 4 April 2012 18:13, Steve Ebersole<steve(a)hibernate.org> wrote:
> Done. You can push again. Thanks
> On Wed 04 Apr 2012 11:17:57 AM CDT, Steve Ebersole wrote:
>> I am starting the release process for ORM 4.1.2. Please do not push
>> changes to master for the time being. Thanks.
> hibernate-dev mailing list