uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Bug in the release process: scm location in release pom points to rc
Date Tue, 03 Sep 2013 14:20:38 GMT

On 9/2/2013 10:14 AM, Richard Eckart de Castilho wrote:
> Am 02.09.2013 um 15:26 schrieb Marshall Schor <msa@schor.com>:
>> On 8/31/2013 2:12 PM, Richard Eckart de Castilho wrote:
>>> There is a "bug" in the release process currently used for UIMA projects.
>>> The practice is to make rc release by
>>> - setting the version to the final version
>>> - changing the svn tag location adding -rcX
>>> The practice to accept a release is
>>> - rename the -rcX tag in svn, removing -rcX
>>> The bug is, that the SCM locations in the release POM are then pointing to the
rc SVN location.
>>> What's worse is, that after the release, the accepted rc folder in SVN is renamed,
removing the "-rcX". Consequently, the SVM location in the POM points to nowhere.
>>> Two problems:
>>> - the SCM location should point to a non-RC tag
>>> - the tag pointed to should not be systematically renamed/removed, making the
SCM location basically worthless
>>> Can we do something about this?
>> One "easy" thing to do is to change our practice, to having mvn release:prepare
>> take the default for the svn tag, without the -rcX suffix.
>> This would make both of these problems go away.
>> It would require manually deleting the svn tag for a "failed" release try, so it
>> could be recreated by the mvn release:prepare.
>> I'm ok with this, given that SVN will keep a history of the rc's if anyone
>> needed to go to a previous one for some reason that I can't think of.
>> WDYT?
> If we wanted to keep the failed RC tags explicitly, we could manually renamed the failed
rc tags to -rcX.
> I'd be both with either solution: delete failed RCs or renamed them after failing.

I have never had a reason to look up a failed rc, myself.  I can imagine one
use-case - suppose a "tester" got confused as to which rc they had downloaded
/tested - they can checkout / compare various rc's against what they have
locally to see which rc they have.  This is versus our current practice, where
the checkout would identify which rc it was. 

Of course, people who checkout for testing could check out a tag (without the
rc) into a local working copy directory which included the rc, to avoid confusion.

So this seems a pretty weak reason to me to worry about this - so I'm in favor
of switching our practice to just using the recommended name suggested by mvn
release:prepare, without an -rc suffix.

> -- Richard
>> -Marshall
>>> Cheers,
>>> -- Richard

View raw message