click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
Subject Click Release Strategy
Date Mon, 04 May 2009 11:45:35 GMT
Hi All,

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 click.sourceforge.net 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.

This strategy would also require less effort to maintain and develop.

With regard to the 2.x and 3.x release strategy, I have been giving
this a bit of thought. While I have been favouring the concept of a
3.x strategy which sounds more exciting, I now think an incremental
2.x strategy, which Bob has been advocating, would be better. If we
have a big bang 3.x release we will need a bunch of milestone releases
before we can make it a production release, and until its a production
release, many people will hold out. I think this was the case with
version 1.5 which took about 7 months of development to complete.

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.

regards Malcolm Edgar

Mime
View raw message