click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <>
Subject Re: Click Release Strategy
Date Tue, 12 May 2009 12:13:28 GMT
Hi Adrian,

Thanks for the comments. Sorry about the late reply, just have been
super super busy last week or so (wife just had a baby boy today, and
I am feeling rather chipper at the moment).

On Tue, May 5, 2009 at 12:36 AM, Adrian A. <> wrote:
>> 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.
> -1 for this.
> Click already migrated to and it should reflect this on
> too.
> I think a much better approach would be the other way around:
> 1. should redirect like it's doing now.
> 2. On the Apache page should be a mention that for older versions, the
> old documentation can be found in:
> 3. a subdirectory somewhere with /old/ in it's path.

The SF version of click is still used in a lot of application
developments, so providing good support that version is important. I
am developing a bunch of SF Click applications at the moment, and
having the SF documentation on line is very useful. We should probably
host an SF version of Click Examples as well.

>> This strategy would also require less effort to maintain and develop.
> What about the patches?
> Many JIRA issues have patches in them (form the community) but were not
> included.
> Should we send more, or should we give up :) ?

The issue we currently have at the moment is time, its easy for the
few Click committers to be over whelmed with JIRA items.

New JIRA feature requests are not necessarily easy to evaluate, as you
have to consider:
* 80/20 guideline, or is this new feature used commonly enough that it
should be included, or will it just bulk out the code base ?
* will the change break backward compatibility, in programmatic
behaviour or rendering, or can it be accommodated as an new option ?
* is the feature simple and largom, is it a good fit for the framework?

Most new features also require an example demonstration in
click-examples, which is also used as a test harness, and
documentation. This often takes just as long or longer than writing
the code.

I think it would probably be more efficient to discuss the issues on
the dev forum and then raise a JIRA item once an approach starts to
come together. Bugs however are a different matter, they should just
go straight into JIRA, bugs are much easier to deal with as they are
generally pretty straight forward.

Regarding some of the JIRA items outstanding you have been discussing:
* Cayenne 3.0M5 update, yes I think we should do this in Click
Examples, and when Cayenne 3.0 goes out move the extras dependency to
* disable class rendering, +1 on this
* checkbox label rendering, been mulling over this and I think we
should support this as a rendering option, with a checkbox rendering
the label on the right hand side, and spanning 2 columns in the form
table grid
*  Link control to be able to render both icon an text - agree with this one

We need to just get cracking and work through your items (easier said
than done).  If we can review your patches as ask for some revisions
it would really help us progress these.

By the way thanks for your time and consideration with these items

>> I would like to get some feedback on this approach.
> For this time, I think it's OK to have this approach.
> After the release of 2.1.0, I think however that the Apache practice
> requires
> to support bug-fix releases too (e.g. 2.1.x).
> After 2.1.0, I think the 1.5.x can be abandoned, since the new fixing branch
> would be 2.1.x.
> Thank you.

Again 1.5.x wont be abandoned, as bugs  identified and fixed are they
will be ported to the respective Apache or SF version.

regards Malcolm Edgar

View raw message