Hi Felix! indeed, we are putting effort on NOT breaking the backwards compatibility with 1.2.X, we updated to version 1.3 - due to some APIs update - and I personally planned to cut the next release keeping that version, so projects like Struts, Sling, ... could adopt it without feeling pain :)
Thanks a lot for supervising that! :) Alles Gute! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Mar 6, 2013 at 3:54 PM, Felix Meschberger <fmesc...@adobe.com> wrote: > Hi, > > Am 06.03.2013 um 14:56 schrieb Simone Tripodi: > >> And, just for the sake of putting more steaks on the barbeque, the >> bundle-plugin takes care of adjusting the version in the MANIFEST.MF >> according to the SemVer recommendations; version is now 1.3-SNAPSHOT >> and look below how the MANIFEST.MF has been generated. > > So here's the topping: The Commons parent POM has configuration to set the > export package version to the same as the project version: > >> <commons.osgi.export>org.apache.commons.*;version=${project.version};-noimport:=true</commons.osgi.export> > > Which is the background, why I spoke about taking care of the export package > version, should you decide to release as 2.0. This would have exported the > packages at 2.0 which in OSGi semantic versioning terms would constitute a > backwards compatibility breaking release, which is probably not the intent of > the Commons project.... > > Regards > Felix > >> >> alles gute! >> -Simo >> >> $ cat target/osgi/MANIFEST.MF >> Manifest-Version: 1.0 >> Bnd-LastModified: 1362567127928 >> Build-Jdk: 1.6.0_37 >> Built-By: stripodi >> Bundle-Description: The FileUpload component provides a simple yet flexi >> ble means of adding support for multipart file upload functionality >> to servlets and web applications. >> Bundle-DocURL: http://commons.apache.org/fileupload/ >> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt >> Bundle-ManifestVersion: 2 >> Bundle-Name: Commons FileUpload >> Bundle-SymbolicName: org.apache.commons.fileupload >> Bundle-Vendor: The Apache Software Foundation >> Bundle-Version: 1.3.0.SNAPSHOT >> Created-By: Apache Maven Bundle Plugin >> DynamicImport-Package: javax.portlet >> Export-Package: org.apache.commons.fileupload.util;version="1.3.0.SNAPSH >> OT",org.apache.commons.fileupload.disk;version="1.3.0.SNAPSHOT",org.apa >> che.commons.fileupload;version="1.3.0.SNAPSHOT",org.apache.commons.file >> upload.servlet;version="1.3.0.SNAPSHOT",org.apache.commons.fileupload.p >> ortlet;version="1.3.0.SNAPSHOT" >> Import-Package: javax.servlet,javax.servlet.http,org.apache.commons.io,o >> rg.apache.commons.io.output >> Include-Resource: META-INF/LICENSE.txt=LICENSE.txt,META-INF/NOTICE.txt=N >> OTICE.txt >> Tool: Bnd-1.50.0 >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> On Wed, Mar 6, 2013 at 2:32 PM, Benedikt Ritter <brit...@apache.org> wrote: >>> 2013/3/6 Felix Meschberger <fmesc...@adobe.com> >>> >>>> Hi, >>>> >>>> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter: >>>> >>>>> 2013/3/6 sebb <seb...@gmail.com> >>>>> >>>>>> On 6 March 2013 08:53, Simone Tripodi <simonetrip...@apache.org> wrote: >>>>>>>>> Is there anybody that can suggest how to handle that situation? >>>>>>>> >>>>>>>> Create new methods which return long rather than int; deprecate the >>>> old >>>>>> methods. >>>>>>>> >>>>>>>> e.g. >>>>>>>> >>>>>>>> @Deprecated >>>>>>>> public int getContentLength() { ... } >>>>>>>> >>>>>>>> /** >>>>>>>> * @since x.x >>>>>>>> */ >>>>>>>> >>>>>>>> public long getLongContentLength() { ... } >>>>>>>> or >>>>>>>> public long getContentLengthLong() { ... } >>>>>>>> or >>>>>>>> public long longContentLength() { ... } >>>>>>> >>>>>>> that should be enough to bump to 1.3.0 since there are APIs addition - >>>>>>> do you agree? >>>>>> >>>>>> Yes, except it should be 1.3, not 1.3.0. >>>>>> If a point release is then required, it is 1.3.1, but point releases >>>>>> are fairly rare. >>>>>> >>>>> >>>>> Having OSGi this may not be the best convention, as OSGi requires version >>>>> numbers to have 3 digits. >>>> >>>> Not really, 1.3 is a perfectly valid OSGi version, too. Actually, even 1 >>>> is a valid version (according to the OSGi Syntax) >>>> >>> >>> Hi Felix, >>> >>> thanks for enlighting me about OSGi once again :) >>> >>> Benedikt >>> >>> >>>> >>>> Regards >>>> Felix >>>> >>>>> >>>>> Benedikt >>>>> >>>>> >>>>>> >>>>>>> -Simo >>>>>>> >>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>> http://simonetripodi.livejournal.com/ >>>>>>> http://twitter.com/simonetripodi >>>>>>> http://www.99soft.org/ >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> http://people.apache.org/~britter/ >>>>> http://www.systemoutprintln.de/ >>>>> http://twitter.com/BenediktRitter >>>>> http://github.com/britter >>>> >>>> >>>> -- >>>> Felix Meschberger | Principal Scientist | Adobe >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> >>> -- >>> http://people.apache.org/~britter/ >>> http://www.systemoutprintln.de/ >>> http://twitter.com/BenediktRitter >>> http://github.com/britter >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > -- > Felix Meschberger | Principal Scientist | Adobe > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
