Christian, I think you are right, we should include a micro number for bug fixes.
As for the source release per language, I think it's probably not necessary. Getting the whole source package and deleting the languages you don't need seems appropriate. I don't think the source packages will be very big (especially since most of the code is generated). The detriment to individual source packages is that each one would have to contain the common XML definitions, or we'd have to have a separate package for these. I'll leave it up to you what the best Java binary format is. Do you believe there will be two different Java binary formats? Regards Paul -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Floerkemeier Sent: Wednesday, August 22, 2007 6:09 PM To: LLRP Toolkit Development List Subject: Re: [ltk-d] release naming and versioning Paul, I just had a few questions regarding your proposal. > I think having a common version number across all languages is beneficial for a few reasons: > Reduced version complications. (e.g. today we released C version 1.6 and Java version 1.4 ????) Are we adopting a release numbering scheme without micro numbers? Does that mean that bug fixes lead to increments of the minor version? > A source package will be released at each LTK target milestone that will contain: > > All documentation for all languages > General documentation on LTK > Common definitions and any vendor extension definitions that have been submitted > and tested > All source (no auto generated components) and makefiles for all languages Is there a reason why there will be no source packages per implementation? I could imagine a Perl developer might not necessarily want to get the Java source as well. I guess he could just access the CVS instead. > A binary package will be released for each language at each LTK target milestone that meets the milestone feature list including: For the Java library it might be best to publish a version in the common jar (java archive) format as well. This would facilitate integration for java developers. ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Dietrich Sent: Freitag, 17. August 2007 12:13 To: LLRP Toolkit Development List Subject: [ltk-d] release naming and versioning All As several libraries are approaching Beta (feature complete), I wanted to get some thoughts out to the group on versioning and naming of deliverables. Can you provide feedback on the following? I'll assume that no feedback means this is an appropriate starting place. We will have two kinds of release: milestone releases and daily drops. Milestone releases will appear on sourceforge and llrp.org. Maintainers of each language will be responsible for building the milestone releases and release notes. The llrpadmin will set the release schedule and tag the CVS tree with the appropriate release numbers in advance of the release date to give maintainers tine to build and test releases. Daily drops will be automated and appear on sourceforge; they are intended for developer and test use only. I think having a common version number across all languages is beneficial for a few reasons: Reduced version complications. (e.g. today we released C version 1.6 and Java version 1.4 ????) The common files can share the same version. If they don't we're likely to get pretty confused. (e.g. C version 1.2 is built on common llrpdef.xml version 1.6, but Java Version 1.2 is built on common llrpdef.xml 1.2). It's a good way to qualify feature sets independent of language. For example, 1.0 will contain a feature set across all languages (of course exceptions will be allowed). Daily drops will contain a CVS tarball will be made of the whole archive and placed on sourceforge in the download area and will only be versioned with the date. LTK_Nightly_date.zip LTK_Nightly_date.tgz A source package will be released at each LTK target milestone that will contain: All documentation for all languages General documentation on LTK Common definitions and any vendor extension definitions that have been submitted and tested All source (no auto generated components) and makefiles for all languages The pakage will be release under two compression formats with the following naming convention where Maj and Min are the Major and Minor release numbers respectively. LTK_Source_Maj_Min.tgz LTK_Source_Maj_Min.zip A binary package will be released for each language at each LTK target milestone that meets the milestone feature list including: The LLRP.xsd. API documentation for the language Header files Compiled library (windows) Example source The packages will be released under two compression formats with the following naming convention LTK_<lang>_Maj_Min.zip LTK_<lang>_Maj_Min.tgz (only for non-windows releases) A Common package will released at each LTK target milestone including: The LLRP xsd. General documentation All vendor definitions submitted to the site. Core llrpdef.xml and llrpdef.xsd files The packages will be released under two compression formats with the following naming convention LTK_Common_Maj_Min.zip LTK_Common_Maj_Min.tgz ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
