click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <>
Subject Re: Click Release Strategy
Date Fri, 08 May 2009 15:27:33 GMT
Hi Malcolm,

Malcolm Edgar wrote:
> I have been giving a bit of thought to the Click versioning/branching
> strategy with respect to is potential use.
> I think we should run with 2 development streams:
> 2.x - Apache Click, this is where the framework is progressing, and
> where new projects should go
> 1.5.x - SourceForge Click, this just includes bug fixes, and is there
> to support project developed with SF Click previously.
> I don't think the Apache Click 2.0.x branch will add a lot of value,
> because if you had a previous SF project, you would either stick to
> the SF version or upgrade to the 2.x version to get new features.
> There is little incentive to migrate an SF application to 2.0.x, go
> through that work and then get no functional benefits.
> This also make the choices much clearer to people. If they look at
> Apache Click they just see the latest (2.x) version available, and
> don't see 1.5.x, 2.0.x and 2.x and try and figure out which they
> should use. In this vein, I think should point
> to a SF version of the Click documentation, but should include a
> notice on the SF home page that this is a maintenance version, and
> people should consider migrating to Apache Click to get the latest
> features. This provides better support for SF users as they can see
> the SF documentation on-line.

+1, I find all the versions on the Apache site confusing and having to 
backport fixes to multiple versions is a pain.

> If we do smaller time box releases (2-3 months), with incremental
> feature improvements these can be production releases and people can
> continually upgrade. With more frequent releases we can publish more
> announcements and generate more press.  If we has a regular release
> schedule, people will also be more confident in the project's roadmap.
>  With a more frequent production release strategy it will require care
> to ensure upgrades are not disruptive.
> I would like to get some feedback on this approach.

We can probably push out 1.5.2 from SF and start looking at releasing 
2.1.0 once a new Calendar is in place.



View raw message