|[eclipse.org-architecture-council] [Bug 327830] New: We need to do a better job educating and helping folks with their version numbers|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=327830 Product/Component: Community / Architecture Council Summary: We need to do a better job educating and helping folks with their version numbers Classification: Eclipse Foundation Product: Community Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: Architecture Council AssignedTo: eclipse.org-architecture-council@xxxxxxxxxxx ReportedBy: irbull@xxxxxxxxxxxxxxxxx I noticed that the a Feature in SR1 had a version number less than that of SR0. In SR1 the version was 3.0.0.R30x.... whereas in SR0 it was 3.0.0.v201005.... Because qualifiers are compared using strings, the 'v' comes after the 'R'. While I brought this to the attention of the team in question, I think this raises a bigger concern. We put a lot of faith in our version numbers, and it's very easy to get these wrong. API tools help, but they won't necessarily catch bundles / features that are going backwards in time (especially if you don't update your baseline). I think we need two things here: 1. Some general education about versions and the consequences of getting these wrong. -- I assume once you've 'released' something with a version, you should *never* go back. 2. Some tooling in the release train to help catch backward versioning. -- Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
Back to the top