[Bug 1745] New: VERSION file does not track RTEMS version

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1745

           Summary: VERSION file does not track RTEMS version
           Product: RTEMS
           Version: HEAD
          Platform: All
        OS/Version: RTEMS
            Status: NEW
          Severity: normal
          Priority: P3
         Component: misc
        AssignedTo: joel.sherrill at oarcorp.com
        ReportedBy: dufault at hda.com


The version file doesn't track the RTEMS version.  This isn't good, unreleased
4.11 still says 4.9.99.  I had a local HG repository I assumed was corrupt (I'm
trying out HG) and I also thought I must have set something sticky in CVS.

RTEMS uses a major.minor.patch versioning scheme, as do I, but I use ".X" for
unreleased versions while RTEMS reserves .99.  For what it's worth here's what
I do.  I'll use for 4.10 and 4.11 in the example

1. The VERSION file always mirrors the release label.  The tip of HEAD is
always labeled major.minor.X, e.g., 4.11.X.

2. When I cut a release e.g. 4.10:
- 4.10 branches.  The tip of that branch immediately becomes 4.10.0.  The
VERSION file is be updated to 4.10.0;
- The HEAD becomes 4.11.X, that is, unreleased 4.11.  VERSION is updated to
4.11.X.

3. I do one thing I don't think is important at RTEMS.  I also label the tips
of the branches with .X, so at branch 4.10.0 is both 4.10.0 and 4.10.X.  Then
if I need to start working on a patch release the VERSION file is changed back
to 4.10.X (untraceable), and the 4.10.X label is moved along any files until I
put down the 4.10.1 label, at which time I update VERSION to 4.10.1.  Those
intermediate files have no version label on them, and so it's obvious they were
never in a release.

4. I am free and easy with patch releases.  I'll go to a client with 4.10.0
planning to leave with 4.10.1, and other than the commit dates, there is no
method of seeing what is a consistent set of files.  That may be unacceptable
for RTEMS.  If so, I'd use labels such as 4.11.X.0, 4.11.X.1, etc. to represent
two 4.11 release candidates and be sure to update VERSION as appropriate.

I hope this isn't too obvious, pedantic, or verbose.  Other than notes (3) and
(4) you can replace "4.11.X" with "4.10.99" and have what I think is the
currently un-enforced RTEMS scheme.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.