I actually find this clearer too. Like the odd/even micro release scheme. Will then try to release version 2.0.2 of http service when I have fixed the md5/sha1 issue.
On Thu, Oct 1, 2009 at 5:12 PM, Felix Meschberger <fmesc...@gmail.com>wrote: > Hi, > > Sten Roger Sandvik schrieb: > > So, what you guys are saying is... > > > > * Keep trunk as a major release, ex 2.1.0-SNAPSHOT. > > * Release minor releases 2.0.1 and still keep trunk as 2.1.0-SNAPSHOT. > > * When 2.1.0 is released, update trunk to 2.2.0-SNAPSHOT. > > > > Right? > > I personally, and my framework, find this confusing. Consider this: > > * my app is running 2.0.2 > * testing some stuff in 2.1.0-SNAPSHOT > * now 2.0.4 is released (including the tested stuff) > * so now I have to "downgrade" to 2.0.4 > > This works by manually downgrading. Using OBR such a downgrade is not > easily possible. > > For this reason, I more like this: > > * work on 2.0.1-SNAPSHOT (trunk) > * release micro release 2.0.2 > * continue with 2.0.3-SNAPSHOT in trunk > * decide to do a minor release 2.2.0 > * continue with 2.2.1-SNAPSHOT in trunk > > This way we have a strictly increasing version numbering and only upon > release we decide what kind of release we do and have not interruption > or "downgrade" > > Recent examples of me having done this is Web Console, which I release > to 2.0.0 after working at 1.2.11-SNAPSHOT in trunk or Configuration > Admin, which was released 2.0.0 after working at 1.0.11-SNAPSHOT in > trunk. Finally, I plan on release the SCR bundle at 1.2.0 while > currently I have it a 1.0.9-SNAPSHOT until ready for release. > > Just my €.02 > > Regards > Felix > > > > > /srs > > > > On Thu, Oct 1, 2009 at 4:43 PM, Richard S. Hall <he...@ungoverned.org > >wrote: > > > >> On 10/1/09 16:36, Felix Meschberger wrote: > >> > >>> Hi, > >>> > >>> Sten Roger Sandvik schrieb: > >>> > >>> > >>>> You are right. We should probably skip version 2.0.0 and go ahead to > do a > >>>> version 2.0.1. I do not tag 2.0.0 since it's a failed release. > >>>> > >>>> > >>> Or brather 2.0.2 because this is bundle release. The reason has been > >>> outline before but basically it is because Maven thinks 2.0.1 is more > >>> recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more > >>> recent. > >>> > >>> For this reason we reserve odd numbers for SNAPSHOTs and even numbers > >>> for releases. [This rule only applies for bundles and not for maven > >>> bundles were we just increment as usual] > >>> > >>> > >> While this is true, it really depends when it comes to micro releases. > >> > >> For the framework we are typically working toward the next minor > release, > >> e.g., 2.1.0-SNAPSHOT in trunk. However, when we go to cut the release, > if it > >> is only a maintenance release, then we release it as 2.0.1 and there > never > >> was a 2.0.1-SNAPSHOT. Then trunk stays at 2.1.0-SNAPSHOT. In other > words, > >> our trunk is never a micro release, it is always a minor (or major) > release. > >> > >> On the other hand, if a subproject operates as a micro release in trunk, > >> then yes they should likely follow the even/odd numbering strategy to > avoid > >> version number inversion like you suggest. > >> > >> -> richard > >> > >> > >> Regards > >>> Felix > >>> > >>> > >>> > >>>> / srs > >>>> > >>>> On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hall<he...@ungoverned.org > >>>>> wrote: > >>>> > >>>> > >>>>> On 9/30/09 23:31, Sten Roger Sandvik wrote: > >>>>> > >>>>> > >>>>> > >>>>>> Thanks for the feedback. I will check out the MD5 and SHA1 digests. > >>>>>> Also > >>>>>> will fix the issues that you are listing here. Was not sure how to > do > >>>>>> the > >>>>>> NOTICE file so it was just a copy from something else :-) Do it need > to > >>>>>> be > >>>>>> a > >>>>>> 2.0.1 release? Could I just rollback the release by rolling back the > >>>>>> pom's > >>>>>> and delete the tag? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> For me, personally, I don't care. However, officially, the issue is > >>>>> since > >>>>> it was a failed release, we shouldn't release it all, because some > >>>>> people > >>>>> might have grabbed the last JARs and are treating them as the > official > >>>>> release knowingly or not. So, the only way to prevent that is to not > >>>>> have > >>>>> that release version at all, which means we do 2.0.1 instead. > >>>>> > >>>>> As for why the digests failed in the first place, I don't really > know. I > >>>>> thought Maven just did this automatically. I am a release newbie > myself, > >>>>> so > >>>>> maybe someone else has some advice. > >>>>> > >>>>> -> richard > >>>>> > >>>>> > >>>>> BR, > >>>>> > >>>>> > >>>>>> Sten Roger Sandvik > >>>>>> > >>>>>> On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hall< > he...@ungoverned.org > >>>>>> > >>>>>> > >>>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>>> -1 > >>>>>>> > >>>>>>> There are quite a few issues, but it is really not all that > >>>>>>> bad...actually, > >>>>>>> there is only one issue that is causing me to give a -1, which is > the > >>>>>>> fact > >>>>>>> that the MD5 and SHA1 digests don't appear to match for me. Not > sure > >>>>>>> why > >>>>>>> that would be the case. > >>>>>>> > >>>>>>> There are also a raft of other more minor issues that would not > have > >>>>>>> caused > >>>>>>> a -1 necessarily, but now we can fix those too. They are: > >>>>>>> > >>>>>>> * The dependencies on OSGi should be on the official JARs at the > >>>>>>> appropriate version level needed (i.e., lowest acceptable > >>>>>>> version). > >>>>>>> * It appears that all NOTICE use the same name (Apache Felix HTTP > >>>>>>> Service), but it should be different for each subproject > module. > >>>>>>> For example, the bridge module should be "Apache Felix HTTP > >>>>>>> Service Bridge". > >>>>>>> * NOTICE file for api says it includes OSGi code, but it doesn't. > >>>>>>> Should also include Apache under "uses". > >>>>>>> * NOTICE file for base says it includes OSGi code, but it > doesn't. > >>>>>>> Should also include Apache under "uses". > >>>>>>> * NOTICE file for bridge should include Apache under "uses". > >>>>>>> * NOTICE file for bundle should include Apache under "uses". > >>>>>>> * NOTICE file for jetty should include Apache under "uses". > >>>>>>> * NOTICE file for proxy says it includes OSGi, but it only uses. > >>>>>>> Also should include Apache in "uses". > >>>>>>> * NOTICE for samples bridge WAR file is not in META-INF > directory, > >>>>>>> neither are LICENSE files. Should verify dependencies listed in > >>>>>>> NOTICE file. > >>>>>>> * NOTICE for samples filter says it includes OSGi, but it only > uses. > >>>>>>> Also should include Apache in "uses". > >>>>>>> * NOTICE for samples whiteboard says it includes OSGi, but it > only > >>>>>>> uses. Also should include Apache in "uses". > >>>>>>> * NOTICE for whiteboard says it includes OSGi, but it only uses. > >>>>>>> Also should include Apache in "uses". > >>>>>>> > >>>>>>> Note that if we have dependencies on Apache software, we still list > >>>>>>> them > >>>>>>> in > >>>>>>> the "uses" section of the NOTICE file...this is overly cautious, > but > >>>>>>> not > >>>>>>> a > >>>>>>> big deal if we already have to keep track of third-party > dependencies. > >>>>>>> > >>>>>>> Doing a release is difficult, so trying it as a newbie is to be > >>>>>>> commended. > >>>>>>> :-) At this point, we will need to scrap this release and do a > 2.0.1 > >>>>>>> release > >>>>>>> with fixes for all of the above. Still, the main issue was the > >>>>>>> digests. > >>>>>>> > >>>>>>> Sorry, but good work none the less. Let me know if you have any > >>>>>>> questions. > >>>>>>> > >>>>>>> -> richard > >>>>>>> > >>>>>>> > >>>>>>> On 9/28/09 22:59, Sten Roger Sandvik wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Hi. > >>>>>>>> > >>>>>>>> I have prepared a release candidate for the improved http service > >>>>>>>> that I > >>>>>>>> contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's > a > >>>>>>>> major > >>>>>>>> refactoring and includes much more functionality than the original > >>>>>>>> http.jetty module. Docs will be available on wiki very soon. > >>>>>>>> > >>>>>>>> This is my first release ever so hopefully I have done all the > things > >>>>>>>> right > >>>>>>>> :-) > >>>>>>>> > >>>>>>>> We solved 7 issues in this release: > >>>>>>>> > https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224 > >>>>>>>> > >>>>>>>> There are 8 outstanding issues: > >>>>>>>> https://issues.apache.org/jira/browse/FELIX/component/12310340 > >>>>>>>> > >>>>>>>> Staging repository: > >>>>>>>> > https://repository.apache.org/content/repositories/felix-staging-007/ > >>>>>>>> > >>>>>>>> You can use this UNIX script to download the release and verify > the > >>>>>>>> signatures: > >>>>>>>> > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > >>>>>>>> > >>>>>>>> Usage: > >>>>>>>> sh check_staged_release.sh 007 /tmp/felix-staging > >>>>>>>> > >>>>>>>> Please vote to approve this release: > >>>>>>>> > >>>>>>>> [ ] +1 Approve the release > >>>>>>>> [ ] -1 Veto the release (please provide specific comments) > >>>>>>>> > >>>>>>>> This vote will be open for 72 hours. > >>>>>>>> > >>>>>>>> > >>>>>>>> Best Regards, > >>>>>>>> Sten Roger Sandvik > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > > > >
