Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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