incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn Dashorst" <martijn.dasho...@gmail.com>
Subject Re: Again: The Maven Repository
Date Thu, 26 Jun 2008 15:17:03 GMT
On Thu, Jun 26, 2008 at 4:58 PM, Emmanuel Lecharny <elecharny@apache.org> wrote:
>> I'd suggest also to rename the packages only when
>> you are almost ready to graduate. This allows you to merge current
>> development and maintenance quite easily.
>
> This is only if you intent to keep both subversion repo alive in //. But if
> users base their development on apache Jsecurity version, they will find it
> painfull to change the package at the very last moment. Don't know ...

In the Wicket case we migrated the committers to Apache, but left the
user community at sourceforge (our user list was migrated when we
graduated). I think for existing projects that start incubation it is
wise to move the committers first, and users upon graduation. Which
doesn't say that users shouldn't use incubator code, but I'd rather
not depend too heavily on podlings. Not only is there a risk of failed
incubation, the podling will have a different focus while in the
incubator: learning the Apache Way. So during this learning things
will slow down a bit or speed up, depending on how incubation goes.
But you'll see different stages: community building, legal vetting,
release building, etc. These will slow down the podling's feature
matrix implementation.

I think moving to the apache namespace early is not advisable. If the
incubation fails for whatever reason, your users need to migrate their
code twice. For users it it not too big a problem to rename their
packages once. With Wicket we did it at the last possible moment iirc
(at least when we got our act together and started our serious
graduation effort)

> What
> if they release a preliminary version on Apache with the new packages, and
> make it the base for the incubator developments, so that users can use it
> straight away and benefit from the new features JSecurity will implement in
> the near future ? It can alleviate the burden of maintaining two different
> code bases, out of which one is known to be dead...

That is not nice for your existing users that depend on jsecurity in
production systems. The Wicket devs have recently released Wicket
1.2.7 outside the foundation for those systems that are dependent on
wicket 1.2.x code, while we already had 1.3.2 out. Not everybody has
the luxury to migrate with the latest and greatest. Though we did
end-of-life our wicket 1.2.x branch with 1.2.7.

> This work too. Depends on the existing user's base, I guess ?

Which was in the thousands for Wicket at the time, with numerous
systems in production.

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message