Hi, 2014-10-08 13:24 GMT+03:00 Jean-Baptiste Onofré <[email protected]>: > No, > > it's not Apache compliant ;) > > An Apache release has to respect rules (verification, etc): sign, legal > checks, etc. > > Regards > JB
Technically, the Apache Foundation is only concerned about source releases. Binaries are just a convenience to users. See [1] section 'What is a Valid Release Package?' . Users however are accustomed to binaries being available . It makes it easy for projects to attract users this way also. [1] http://www.apache.org/dev/release-publishing#goal > On 10/08/2014 12:20 PM, Charlie Mordant wrote: >> >> Hi Jean-Baptiste, >> >> I'm not speaking about nightlies/snapshot's, but real Maven Central >> releases (with a X.Y.Z+1 version), continuous delivery aims to release >> in production, not in a testing/snapshots env. >> >> The challenge is in deciding when to fire a release: a major/blocking >> Jira resolved, a code quality reached, 4 weeks after the last... And how >> to ensure the stability of the product (80% test coverage and 90 Itest?). >> >> It's more than a nightly, as it is not a daily baked product and more a >> decided one, the thing is that it is fully automated. >> >> Regards >> >> >> >> 2014-10-08 11:46 GMT+02:00 Jean-Baptiste Onofré <[email protected] >> <mailto:[email protected]>>: >> >> Hi Charlie, >> >> We already have Jenkins and nightly builds. But I'm not sure a lot >> of people uses/tests the SNAPSHOTs. >> >> Regards >> JB >> >> On 10/08/2014 11:33 AM, Charlie Mordant wrote: >> >> Hi, >> +1 for a short lifecycle. >> >> I'm not totally for what I'll ask but it's an alternative >> solution: >> What about continuous deployement? >> A Jenkins build pipeline that will trigger Jira ticket >> resolution then >> releasing Karaf if all tests pass? >> I really don't know if it's a viable solution, but it would make >> the >> thing :). >> >> Best regards, >> >> 2014-10-08 10:46 GMT+02:00 Jamie G. <[email protected] >> <mailto:[email protected]> >> <mailto:jamie.goodyear@gmail.__com >> <mailto:[email protected]>>>: >> >> +1 >> >> There will always be another upstream fix to wait for, a >> short Karaf >> update cycle seems to be the best approach to avoiding >> extended >> delays. >> >> --J >> >> On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck >> <[email protected] <mailto:[email protected]> >> <mailto:bcanhome@googlemail.__com >> <mailto:[email protected]>>> wrote: >> > Hi, >> > >> > I'm in big favor of having a hard release cycle on 6 weeks >> (minimum I'd >> > actually prefer 4 ;) ) >> > Regarding the thoughts about 3party dependencies, >> actually it's >> the reason >> > we don't get our own bugfixes out fast right now. >> > Actually I'd say screw it. No more waiting for 3rd party >> dependencies ... >> > get the stuff out fast cause 4-6 weeks later you have >> the next >> > release picking up the issue. >> > >> > regards, Achim >> > >> > >> > 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>: >> >> >> >> >> >> That's why we have an extend of 2 weeks to deal with >> other projects. >> >> >> >> Regards >> >> JB >> >> >> >> On 10/08/2014 08:16 AM, Christian Schneider wrote: >> >>> >> >>> Generally I agree that we should aim for such a cycle. >> >>> I only hope it is possible as we depend a lot on other >> projects >> that we >> >>> bundle. So a lot of the time a release waits on fixes or >> releases in >> >>> upstream projects. >> >>> >> >>> Christian >> >>> >> >>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré: >> >>>> >> >>>> Hi all, >> >>>> >> >>>> Users complained about the variable and long delays >> between Karaf >> >>>> releases. It's a fair comment and it's something that >> we have to >> >>>> improve. >> >>>> >> >>>> I propose the following new policy about the releases >> cycle: >> >>>> - for "active" branches (3.0.x and 2.4.x), I propose >> a release >> every 6 >> >>>> weeks, with maximum extend to 8 weeks. >> >>>> - for "eol" and "maintenance" branches (2.2.x and >> 2.3.x), it's "on >> >>>> demand", no strong cycle there. >> >>>> >> >>>> WDYT ? >> >>>> >> >>>> If everybody agrees, I will update the releases >> schedule page >> on the >> >>>> website. >> >>>> >> >>>> Regards >> >>>> JB >> >>> >> >>> >> >>> >> >> >> >> -- >> >> Jean-Baptiste Onofré >> >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> >> http://blog.nanthrax.net >> >> Talend - http://www.talend.com >> > >> > >> > >> > >> > -- >> > >> > Apache Member >> > Apache Karaf <http://karaf.apache.org/> Committer & PMC >> > OPS4J Pax Web >> <http://wiki.ops4j.org/__display/paxweb/Pax+Web/ >> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> >> Committer & >> > Project Lead >> > blog <http://notizblog.nierbeck.de/__> >> > >> > Software Architect / Project Manager / Scrum Master >> > >> >> >> >> >> -- >> Charlie Mordant >> >> Full OSGI/EE stack made with Karaf: >> https://github.com/__OsgiliathEnterprise/net.__osgiliath.parent >> <https://github.com/OsgiliathEnterprise/net.osgiliath.parent> >> >> >> -- >> Jean-Baptiste Onofré >> [email protected] <mailto:[email protected]> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> >> >> -- >> Charlie Mordant >> >> Full OSGI/EE stack made with Karaf: >> https://github.com/OsgiliathEnterprise/net.osgiliath.parent > > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com -- Ioan Eugen Stan 0720 898 747
