karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [DISCUSS] Migration to SCR
Date Tue, 04 Feb 2014 08:00:19 GMT

I really liked the idea to have a "smaller" core, though I still think it's
major change even if it is internal,
so this should go to a 4.0.
I hope we don't take another 3 years for the next major version, and I
don't plan on supporting this.
Still right now I don't see any value of opening another playground where
we have still plenty to do
with releasing a 2.3.x and 2.4.0 (where 2.3.x will hopefully be the last of
that branch) and of course
we need to harden the 3.0 branch first.
>From what I can tell right now, regarding the 3.0 hardening it is mostly a
one-man show of JB.

So please be patient to get this thing rolling. Everything to make this
transition easier like decoupling
the features, be my guest to add those :D

regards, Achim

2014-02-03 Ioannis Canellos <iocanel@gmail.com>:

> As I mentioned earlier, I am not really interested in the release
> version per se, but primary in the time to market and secondarily on
> what it means in terms of maintenance.
> As in all things, the key is balance.
> Release often is guaranteed way of delivering value to users,
> releasing too often may send out the wrong message (is it just me, or
> people tend to become uneasy with very often major releases?).
> Also releasing very often means, that as a community we will be
> supporting each major release for a small period of time, or we will
> need to increase the number of major versions we support at any given
> time. Do we have the luxury to do so?
> For example, let's assume that we go for a 4.x in say 3 months....
> It has proven a bit hard to maintain the long living 3.x branch along
> with 2.x (module restructures made it not trivial to just cherry-pick
> fixes from one branch to the other). If we add a third branch into the
> mix, it will become even harder.
> So what are we supposed to do here? Push the release back 6 - 12
> months, or until we decide we no longer need to support 2.x? In that
> case we could hold of creating a 4.x branch until we get near that
> time (to avoid the maintenance overhead). We could use this time and
> follow Dan's suggestion about letting other projects adopt the feature
> changes. But still it does sound like a long time which is meant to
> become even longer as "new features" will pile up for 4.x.
> Thoughts?
> --
> Ioannis Canellos
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message