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
