Oh. Right. Now I see. You and Felix has actually the same method, except one uses minor odd/even strategy vs major odd/even strategy?
On Thu, Oct 1, 2009 at 5:15 PM, Richard S. Hall <he...@ungoverned.org>wrote: > On 10/1/09 17:01, Sten Roger Sandvik wrote: > >> 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. >> >> > > Yes, this part would be ok, but... > > * When 2.1.0 is released, update trunk to 2.2.0-SNAPSHOT. >> >> > > No, in this case there will never be a 2.1.0 release, since 2.1.0-SNAPSHOT > would be greater. Here, you'd follow the odd/even strategy, so > 2.1.0-SNAPSHOT would be the development version and when you cut a release > for 2.1.0-SNAPSHOT, it would be released as 2.2.0 and the trunk would become > 2.3.0-SNAPSHOT. Make sense? > > -> richard > > > Right? >> >> /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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >
