[tei-council] Jenkins config changes

[Martin Holmes]

On 12-10-28 12:40 PM, Piotr Banski wrote:
> On 28/10/12 19:55, James Cummings wrote:
> [...]
>> Some projects use odd numbering for 'testing' or 'release
>> candidate' releases and even for actual releases.  I.e. we could
>> do 2.2.1 as a candidate and then even with no significant changes
>> do 2.2.2 as the stable version of it.  Just thinking out loud.
>
> Given the number of post-factum-discovered problems in the recent
> releases, this idea doesn't sound bad. OTOH, these problems are most
> often (?) discovered thanks to the users.
>
> So do you mean that, e.g., 2.2.1 would be released 'silently' (merely
> announced on the homepage and in SF, not on the list), and we would
> count on testers to find some wrinkles?

It wouldn't necessarily be "released" at all; but if you went to the 
lastSuccessfulArtifact on Jenkins, it would show different version 
information. What we'd be testing, among other things, is the effect of 
actually changing the version information. At the moment, that only 
happens on release day, so if it doesn't work properly, we don't know 
until it's too late.

If we went with odd-for-dev, even-for-release numbering, we'd switch 
soon to 2.3.0, with a new "development" version of a readme, and we'd be 
able to see if the change in versioning percolated through correctly to 
all the products. Then when we switched to 2.4.0 for a real release, 
there should be less chance that something odd happens. We could even do 
a test 2.3.1 the day before the final freeze, to be sure the change to 
2.4.0 will go OK.

Only even-numbered builds would be publicly released and placed in the 
Vault.

Cheers,
Martin

Cheers,
Martin

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre