Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-dev] Results: Version Class changes and the Manifest file 
Based upon the feedback I've received. Revised Option #3 is the winner.
I need to finalize this work, so I will proceed with the changes to the build system and Version class utilizing that standard. 
Therefore:
- the manifest will show a versionString in "Implementation Version" as defined below 
- the Version class will:
- include a main method that prints out version information (java -cp eclipslink.jar org.eclipse.persistence.Version) - include a method that returns the versionString (org.eclipse.persistence.Version.getVersionString()) - include a method that prints just the versionString to Stdout (org.eclipse.persistence.Version.printVersionString()) - Rather than using "prefix-releaseversion-date.suffix", files on the download server will utilize the versionString in their names. 
     (prefix-versionString.suffix => eclipselink-1.1.0.r2739-M3.zip)
As is the practice, I will announce a patch and have it reviewed before committing it later this week. 
Let me know if you have any questions.

-Eric

Tom Ware wrote:
Eric and I just had a chat and we have a slightly revised suggestion (based on option 3): 


(version).r(revision)-(type) or (version).(revision)
where version is: (major).(minor).(patch)

1.1.0.r2312-SNAPSHOT
1.1.0.r2739-M3
1.1.0.r2984

-Tom


Neil Hauge wrote:
The Plug-in Versioning Guidelines may be useful as a reference - http://wiki.eclipse.org/index.php/Version_Numbering. 

Neil

Tom Ware wrote:

I guess we need to figure out if we would ever need 4 or more digits.

Eric Gwin wrote:
Point taken, and I agree there could be confusion (though 1.1.1 would look like 1.1.1.2991-SNAPSHOT or 1.1.1.3267 (release)).
Therefore we should ALWAYS specify all the digits in our version. If we are going to use a three number versioning scheme (major).(minor).(bugfix), then we should always display the full version. 

ie. 1.1.0.2984 and 1.1.1.3267

-Eric

Tom Ware wrote:

I am concerned that will cause confusion at release time.
If we're not careful, it may look like we just released version 1.1.2984. If at some point, we release version 1.1.1, it will look like version 1.1.2984 is more recent, when in fact it is less recent.
Are these changes just for manifest files, or also for jar file naming? 

-Tom

Eric Gwin wrote:

Sounds like Option 4:
-----------------------
It does distinguish revision from the version. Though I put the period in because it blends it all into a single "Version Number". 

-Eric

Tom Ware wrote:
In your proposed solution, can we change the last "." to some other character 

e.g.
1.1-2312-SNAPSHOT


Eric Gwin wrote:
Seems to be little interest on the topic, but I need to at least pass this by the group so I'd like a vote today.
I'll put a +1 next to my choice. If there are no other votes, I guess it'll win by default.
As an aside, MW currently uses something completely different. I plan on setting this up to be consistent across EclipseLink 


"Implementation-Version" in the manifest:
_Option 1:_
(version)(type)-(date).(revision) or (version)-(date).(revision)
1.1SNAPSHOT-20081006.2312
1.1M3-20081029.2739
1.1-20081125.2984

_Option 2:_
(version).(type).(revision) or (version).(date).(revision)
1.1.20081006.2312
1.1.M3.2739
1.1.20081125.2984

_Option 3 (+1):_
(version).(revision)-(type) or (version).(revision)
1.1.2312-SNAPSHOT
1.1.2739-M3
1.1.2984
The first option results in a string closest to what we currently use (but with the addition of the revision).
The second is the result of minimally changing the build methodology.
The third makes the most sense to me. It gives the version and a unique build identifier (revision), is clean and easy to on the eyes, yet still has distinctions for nightly, milestone and release builds. However it diverges significantly from what we currently use. 

Thanks.

-Eric
------------------------------------------------------------------------ 

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Back to the top