>... we should include a micro number for bug fixes. Just one more question question regarding the release versioning. Are we adopting a set of guidelines that indicate what changes to major, minor, and micro (patch) number mean, e.g. http://apr.apache.org/versioning.html? This might be helpful for application developers.
> 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. Ok. We all agreed a while back that it is not a good idea to have generated sources in the version control systems. I am not sure whether this precludes making the generated sources available for download. In Java, the (generated) sources will provide the documentation (javadoc) to IDEs and developers might find the generated sources handy to report bug fixes. > 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? I think we would publish the LTK Java binary in the java archive format (jar) only. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Dietrich > Sent: Freitag, 24. August 2007 19:29 > To: LLRP Toolkit Development List > Subject: Re: [ltk-d] release naming and versioning > > 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 > ------------------------------------------------------------------------- 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
