466139 - [redux] Version numbers

Status: VERIFIED FIXED

(Tamarin Graveyard :: Virtual Machine, defect, P3)

Description

[Lars T Hansen]

Attachment: Patch

Rework the version numbering in Tamarin.

A version number consists of a major version in the form of a name (here "T1" for "Tamarin 1") and a minor version in the form of a release number.  The minor version number is incremented *every time* the release repository is updated (TC in our case) and *never* otherwise.  The major version name is updated when major architectural changes or API incompatibilities are injected (typically this will coincide with the creation of a new release repository).

(Note, the initial patch removes all the old AVMPLUS_VERSION_ definitions; if these are part of some API used by existing embedders then we may have to reconsider that and clean it up as part of the upcoming API work instead.)

Comment 1

[Brent Baker]

During a "release" cycle there may be multiple merges that happen from the redux branch, does this imply that every time a merge happens the minor version is incremented even if it is during the same cycle?

Should the minor version actually only be updated when code changes happen? I have a backlog work item to get the buildbot scripts merged into the branch. I would assume that during that time I would not be updating the minor version.

I assume that the build system will no longer modify the version and it will be up to the committer increment the minor version.

Comment 2

[Steven Johnson]

Comment on attachment 349392 [details] [diff] [review]
Patch

My only concern is that changing the "major version" string every time we change the API is going to cause a lot of churn over the short term -- once we get a stable embedding API that will settle down, but until then it will probably have to be revised every release.

Comment 3

[Lars T Hansen]

The major version only has to be updated for incompatible API evolutions (because nothing else will break working code, so nobody cares), and even for incompatibilities there are workarounds that we can introduce.  Major API work is churn-heavy regardless; nothing to be done about it.

I think Brent has had other, interesting, objections; I'll try to address those next week.

Comment 4

[Lars T Hansen]

I'm killing this as a dependency for the November 2008 TR -> TC merge, because there's significant discussion about how version numbers should be used and how they fit into our process.  (Nothing like proposing a concrete change to get people discussion!)

Leaving the bug open for now.  I'll add a simple identifying string to the release but not remove any of the existing versioning infrastructure.

Comment 5

[Lars T Hansen]

I don't understand how the current values are used, as the version is 1.0 still and appears always to have been so.

I propose that we add two values to avmVersion.h, a serial number and a string.  The string will be the ISO-format date on which the tamarin-redux repository was branched in order to be merged into tamarin-central, and the serial number is incremented by one every time this happens.

  #define TAMARIN_RELEASE_NUMBER 2
  #define TAMARIN_RELEASE_DATE   "2008-02-14"

The purpose is for the released code to be self-identifying, something it currently is not.  A little goes a long way.

Steven, opinions?

Comment 6

[Rick Reitmaier]

By serial number, in the above comment, do you mean release number?

Comment 7

[Lars T Hansen]

Summary of current proposal (following discussion above and in e-mail thread).

(1) We keep avmplusVersion.h effectively unchanged.  In particular, no new
    names are introduced.

(2) We start using AVMPLUS_MAJOR_VERSION and AVMPLUS_MINOR_VERSION to track
    our work as well as merges from tamarin-redux to tamarin-central, as
    follows.

(3) The major version is updated when we think it is appropriate to do so
    (major technology change, incompatible API changes maybe, new bytecodes
    maybe).  I don't think the rules for this should be set in stone.  It's
    supposed to signify that "something important just happened".  We have
    to just reach a consensus on whether something should trigger a change.

(4) The minor version number is updated on /every/ merge from tamarin-redux
    to tamarin-central and is therefore a serial number for the release.

(5) I do not propose that we do anything with the build number at this time,
    but we should leave it there so that buildbots can fill it in if they like.

(I also think that once the last big changes in the pipeline land - the OOM work, MIR removal, atom reworking, and verifier work - and in commemoration of big things already done - NanoJIT, LIR, new interpreter - we should up the version number to "2".  If all that together isn't "major" then the major version number will probably remain "1" indefinitely.)

If this is acceptable then I will create a patch for avmplusVersion.h containing information about the above rules, and setting the minor version to "1" to reflect the release last November.

Comment 8

[Steven Johnson]

(In reply to comment #7)
> If this is acceptable then I will create a patch for avmplusVersion.h
> containing information about the above rules, and setting the minor version to
> "1" to reflect the release last November.

Sounds good to me.

Comment 9

[Lars T Hansen]

Attachment: new attempt

Comment 10

[Lars T Hansen]

redux changeset:   1427:345bb3a42d20