Skip to main content

[Hudson-Dev] Re: New Hudson version numbering proposal

  • From: Stuart McCulloch <mcculls@...>
  • To: dev@...
  • Subject: [Hudson-Dev] Re: New Hudson version numbering proposal
  • Date: Tue, 15 Mar 2011 12:18:58 +0000

On 15 March 2011 01:12, Denis Tyrell <DENIS.TYRELL@...> wrote:

We’ve had the same consideration on our side that a 4-part is too complicated so we also agree to change the proposal to be a 3-part version.


Sounds reasonable to me - I'm currently experimenting with Hudson on OSGi (which I'll be writing about in another thread very soon) so an OSGi compatible version scheme would be useful

--
Cheers, Stuart
 

 --- 

Denis Tyrell
Senior Director, Server Technologies
Oracle Corp

From: Jason van Zyl [mailto:jason@...]
Sent: Monday, March 14, 2011 5:59 PM
To: dev@...
Subject: [Hudson-Dev] Re: New Hudson version numbering proposal

 

I would suggest using x.y.z-qualifier which will work better with Maven and will be easier to mesh with OSGi (x.y.z.qualifier). I think 4 digits is too granular.

 

On the Maven side the XStream site has a nice summary:

 

 

And on the OSGi side there is the official specification:

 

 

I think we should pick one of those as they are primarily in use. Adding a third major scheme will make interoperability harder.

 

On Mar 14, 2011, at 7:03 PM, Denis Tyrell wrote:



We are proposing a new change to the Hudson version numbering scheme.  Instead of the two part versioning system that is in place now (For example: 1.398), we would like to move to a 4 part system.  The reason for this is to better indicate the impact of a release and what affects if might have on existing installs.  Currently it is difficult to gauge the impact/risk of implementing a new release of Hudson if the same number is incremented for both minor/medium enhancements as for simple bug fixes.  Not all releases are created equal. 

 

Definitions:

Major version:  This would change only when major changes in the framework are put in that could break existing functionality or force non-compatibility to older versions.  (Example:  1.3.4.5  to 2.0.0.0)

Minor version:  This would change when minor feature changes take place or significant but still compatible functionality is added.  (Example:  1.3.4.5 to 1.4.0.0)

Point release:  This would change when a new release of an existing minor version is done to include more defect fixes or very small enhancements to existing functionality.  (Example:  1.3.4.5 to 1.3.5.0)

Patch release:  This would be for bug fixing and small patches only on existing point releases.  If a critical bug fix is required on a specific release, this number would get incremented.  (Example:  1.3.4.5 to 1.3.4.6)

 

Proposal:

Move to this new numbering scheme in our next release, scheduled for ! roughly 4 weeks from now.  Because the existing nu! mbering scheme is already using the minor version, we need to bump the major version up to account for this.  If we do not do this, we face potential issues in the auto-increment facilities.  (Example, 1.399 is still a higher version than 1.4.0.0).  We would like to start with our next version being 2.0.0.0.

 

Comments?

 

--- 
Denis Tyrell 
Senior Director, Server Technologies 
Oracle Corp 


 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

 

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

  -- Jakob Burckhardt

 

 

 




[Hudson-Dev] New Hudson version numbering proposal

Denis Tyrell 03/14/2011

[Hudson-Dev] Re: New Hudson version numbering proposal

Jason van Zyl 03/15/2011

[Hudson-Dev] Re: New Hudson version numbering proposal

Denis Tyrell 03/15/2011

[Hudson-Dev] Re: New Hudson version numbering proposal

Stuart McCulloch 03/15/2011

[Hudson-Dev] Re: New Hudson version numbering proposal

Henrik Lynggaard Hansen 03/15/2011

[Hudson-Dev] Re: New Hudson version numbering proposal

Ted Farrell 03/15/2011
 
 
Close
loading
Please Confirm
Close