On Thu, Jun 26, 2008 at 4:58 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
