+1 I don't really have anything to add. Semantic versioning does not imply per-bundle release cycle, and that was only done because there was some reluctance to release the same identical bundle with different versions (which I don't have any problem with personally).
On Tue, Jun 26, 2012 at 11:46 AM, David Bosschaert <[email protected]> wrote: > This is a slight tangent on the discussion here, but I'd like to share > my thoughts re versioning... > > I personally think that it's not really that important what the bundle > version is and I do like the convenience of having the same version > number of all the bundles that logically belong together as it kinda > has the implied message that these things should work together... > > I think the important thing is that you can still do semantic > versioning regardless of how you version your bundles as semantic > versioning relates to the versioning of exported packages inside those > bundles. In aries this information is stored in the packageinfo files > in the source tree. > > In OSGi you typically depend on other bundles by importing a package > with a certain version range. That's where you are using the semantic > versioning. If you import a package with a version range the name and > version of the bundle providing that package is not important. > > While I do see that there is value in being able to do individual > releases of bundles, I don't really see any issue with doing larger > releases too, and the idea of moving the bundle versions up for all of > them. Also long as you semantically version your exported packages I > think everything should be good... > > Cheers, > > David > > On 26 June 2012 09:06, Achim Nierbeck <[email protected]> wrote: >> Hi >> >> I have to second Dan here. >> As a user it's a PITA to keep track of 3 different versions for all >> the required Blueprint artifacts. >> Just to give you a simple example using Blueprint (0.3.2) with Proxy >> (0.3.1) and JPA (0.3) >> and Transaction (0.3 and 0.3.1). Especially to find the right version >> for the same "kind" of bundles >> is not a intuitive way of doing. I'd rather prefer all bundles of the >> same type to have the same version. >> >> Regards, Achim >> >> 2012/6/25 Daniel Kulp <[email protected]>: >>> >>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks are >>> completely pointless. Nexus generates them itself based on what's >>> uploaded. The "is it a valid signature" part of the GPG testing is also >>> pointless as Nexus won't let you close the repo unless the signatures are >>> valid. The only check you really need to do is to make sure the key that >>> was used is "trusted" by you. (aka: was it really Holly who deployed those >>> artifacts) So the monontonous parts of checking that stuff is really >>> irrelevant at this point. (providing we trust that infra has Nexus >>> sufficiently locked down and secure) >>> >>> >>> I actually don't have a big issue with the difficulting in getting votes. >>> I'm involved in another community that has a PMC that is easily 4 times the >>> size of this one, yet we still have difficulting getting votes there. >>> While not ideal, life events can cause priority shifts and such so people >>> may not be able to be as responsive. >>> >>> My bigger problem is that the entire per bundle release process and symantic >>> versioning crap has put a HUGE burden on the release manager. That makes >>> it much harder to get quality releases out and makes it less likely that >>> anyone will step up to get "minor fixes" released. The only reason I >>> stepped up with the 0.3.1 bp stuff is that *MY* customers are being >>> affected by it. Like wise for the proxy stuff. If *my* customers were >>> not affected, I don't think I would have spent the time and effort. If >>> the process for getting fixes and releases out to users was smaller and >>> easier, I have no problem doing them. For CXF, we do full releases on 3 >>> branches every other month or so. But that's because it's EASY to do. >>> >>> If it was up to me, I'd toss out the entire versioning thing with 1.0 and go >>> back to per module versioning thing. So my fix to proxy would have >>> involved checking out all of "proxy", fixing it, and releasing all of proxy >>> as a proxy "0.3.1", even the modules that haven't changed. It's just a >>> huge hassle to track down which bundles have changed, which haven't which >>> version numbers need to be updated, etc.... If it's not quick and easy to >>> do releases as a release manager, very few people are going to step up to do >>> it. It may not be 100% "proper OSGi", but IMO, getting fixes and such to >>> the users is more important than that. But that's my opinion. >>> >>> >>> Dan >>> >>> >>> >>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote: >>>> Hi all, >>>> >>>> Now that Jeremy's taken the time to write up our release verification >>>> process, I'd like to propose we change it. :) I think it's too onerous >>>> on the pmc, which therefore also inhibits our ability to be responsive >>>> to our users. >>>> >>>> >>>> ------------------------------- Why what we have isn't working for the >>>> community ------------------------------- >>>> >>>> I believe our users would like more frequent releases. We've had >>>> several keen requests and tweets and comments on the aries-user >>>> mailing list wishing we'd release more often. For example: >>>> >>>> * "Desperately waiting for an Aries release after loooong time.." >>>> * "The problem with Aries is they seem to be too busy coding to >>>> release anything." >>>> * "Compared to other projects (like Karaf and Camel) Aries releases >>>> tend to take quite some time." >>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any >>>> chance of a new Aries JPA release any time soon? " >>>> * "Looks like Apache Aries has made no visible progress since Jan >>>> 2011, if the time stamps on the maven central artefacts are to be >>>> believed." >>>> >>>> ------------------------------- Why what we have isn't working for us >>>> ------------------------------- >>>> >>>> Both Dan and I are trying to do releases at the moment, and struggling >>>> to get enough PMC votes. Dan's release is to back port a show-stopper >>>> proxy fix, so a release there is particularly pressing - he's got a >>>> non-binding +infinity vote, but that's all. My test support release >>>> vote has been open for about 64 hours, and only got one vote so far >>>> (thanks David B!). Obviously testsupport is less exciting than proxy, >>>> but that bundle does block more interesting releases. >>>> >>>> Why aren't people voting? My guess is that it's too much work to do >>>> the full set of verifications described at >>>> http://aries.apache.org/development/verifyingrelease.html. There are >>>> seven steps, and while they don't actually take that long to complete, >>>> it's enough of a burden that we tend to leave the voting to someone >>>> else unless we really care about a release. I'm as guilty of this as >>>> anyone - I think a release is a good idea, but I'm spending enough >>>> time working on the 1.0.0 release that I don't want to take time out >>>> to vote on another release. I suspect Dan might feel exactly the same >>>> about my 1.0.0 bundles. :) >>>> >>>> With release-by-bundle, there's a lot of verifications. Excluding the >>>> sandbox code, we have 123 bundles to release in 1.0.0. At three votes >>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP >>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door. >>>> This just doesn't seem like it scales. Batching the bundle releases >>>> together eases some of this burden, but not all. >>>> >>>> ------------------------------- What I propose >>>> ------------------------------- >>>> >>>> I suggest we move to a more trust-based system, where PMC members >>>> carefully check releases if they want, but where in general they're >>>> voting on the principle of the release, rather than the mechanics of >>>> the archives. In particular, they don't feel compelled to do checks >>>> before voting. If PMC members could say "Our users need this function, >>>> so +1", or "I know Holly has done sensible things in the past, so +1" >>>> or even "Do I want to check the SHAs on a test support bundle? Really? >>>> +1" it would get our releases moving better, and also save work for >>>> all of us. >>>> >>>> (At the moment I think what's happening is people are thinking "Do I >>>> want to check the SHAs on a test support bundle? Really?" and then >>>> skipping the +1 bit. :) ) >>>> >>>> To ensure that at least *someone* has run the checks, the release >>>> manager could include the output of the seven checks in an email to >>>> the list. I think this level of checking is perfectly compatible with >>>> the minimum Apache process, which is that the release manager signs >>>> the artefacts and three PMC members vote +1 >>>> (http://www.apache.org/dev/release-publishing.html#voted). >>>> >>>> What do people think? >>>> >>>> Holly >>> -- >>> Daniel Kulp >>> [email protected] - http://dankulp.com/blog >>> Talend Community Coder - http://coders.talend.com >> >> >> >> -- >> >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >> Committer & Project Lead >> OPS4J Pax for Vaadin >> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project >> Lead >> blog <http://notizblog.nierbeck.de/> -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
