This is for apache foundation, but don't forget the engagements of the
apache license (in terms of legal).
Regards
JB
On 10/17/2014 01:24 PM, Ioan Eugen Stan wrote:
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
