I think, JB already published a road-map before.
Basically it boils down to one thing:
"how do you swallow a whale, piece by piece"
So, for me it's more important to have 2.3, 2.4 and 3.0.1 done.
After that let's take a look at the "new" features for 4.0 like
SCR for core, Java7 Support which is
OK then 4.x it is.
And when do u feel its the right time to create a 4.x branch?
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
I have no idea how compatible jetty 9 and pax web 4 are. I think the
question should be if our users would have to do changes in their code.
If yes then we should delay the upgrade to 4.0 if not then there is no
issue.
What I wanted to say about karaf 4 is the way we do our versioning of
pack
Ok, so as far as I'm concerned, we won't do an upgrade to Pax Web 4.0 with
Jetty 9 in a Version 3 then.
regards, Achim
2014-02-04 Christian Schneider :
> I think we should not create a 4.0.0 version without doing incompatible
> changes.
> In marketing major versions are used to tell people that
I think we should not create a 4.0.0 version without doing incompatible
changes.
In marketing major versions are used to tell people that big functional
changes/additions have been done. The idea there is that a major version
sells better.
Our environment is very different though. Technically
Hi,
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 an
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
So, start 4.x now! :) Release early, release often.
On Mon, Feb 3, 2014 at 12:09 PM, wrote:
> Good points Ioannis,
>
> my point is just about the "message" for we send to the users and community.
>
> You are right, it took long time to release Karaf 3.0.0, but it doesn't mean
> that it would
Good points Ioannis,
my point is just about the "message" for we send to the users and
community.
You are right, it took long time to release Karaf 3.0.0, but it doesn't
mean that it would be the same for 4.0.0.
My point is just to send a message for users/community like: "hey, we
did deep
> I would plan this for Karaf 4.0.0, even if it's internal.
While I don't have a strong objection on having it as part of a 4.x
release, that would mean that it will get pushed back way into the
future.
3.x release took us almost 3 years to get out and we stalled 2.3.x for
1.5 year in favour of 3.
I would do #2 first, even in the next patch releases. Having the feature
defined doesn’t cause any problems at all and that way external projects can
start relying on it, even if it is installed by default.
Dan
On Feb 3, 2014, at 9:52 AM, Ioannis Canellos wrote:
> A while back we discuss
-1
I would plan this for Karaf 4.0.0, even if it's internal.
It's an important jump internally in Karaf, and should be addressed in a
major release.
We just release Karaf 3.0.0, and we have to let people and other
projects to move smoothly (even if as you said, you should not have impact).
A while back we discussed about migration from Blueprint to SCR and we
all agreed that it was a nice thing to do.
The question is how to do it, without making maintenance hard and also
without taking ages to deliver this new feature.
I think that this should be done in 3 steps:
i) Migrate from Bl
13 matches
Mail list logo
