Sorry. Yes. On Thu, Oct 1, 2009 at 5:22 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 10/1/09 17:17, Sten Roger Sandvik wrote: > >> 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? >> >> > > Micro and minor, but yes. > > -> richard > > > 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >
