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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >
