click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian A." <>
Subject Re: Click Release Strategy
Date Tue, 12 May 2009 13:01:46 GMT
> 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).
Congratulations :) !

>> 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 ?
Yes, it should be included. The 80/20 is what drives every patch.
If the rule does not apply, it makes no sense for me to loose time in 
making that patch in first place.

> * will the change break backward compatibility, in programmatic
> behaviour or rendering, or can it be accommodated as an new option ?
Backward compatibility is always the requirement.

> * is the feature simple and largom, is it a good fit for the framework?
Yes, yes and yes.

> 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 haven't supplied for most patches example code yet because at this
moment this seems pointless: if you don't include the patches(so far 
none was) my effort is a loose of time anyway, so why should I loose 
twice as much time?

Examples can always be quickly supplied after patches are included. 
Besides, it's not specific to practice to include new 
features just 1 day before the release, so there's enough time to 
include example code(and review it) too before a release is done.

> 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. 
Most issues have my comments (or from other users) but many are not 
answered so far :(.
That's why I asked here about the status one more time.

> 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.
Click is already quite complex (compared to the early versions I was 
used to - 0.xx),
so it's quite improbable that you will get that many bug fix patches 
from the community.
Also, there are few things that one could count as bugs, but because of 
"backward compatibility" they are considered "features".

>>> 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.
> Again 1.5.x wont be abandoned, as bugs  identified and fixed are they
> will be ported to the respective Apache or SF version.
I mentioned this because I saw that 1.5.x also got new features, not 
just bug fixing. I think this will create much more confusion that it 
tries to solve. Combined with the change in the online documentation 
strategy, the confusion will be even bigger IMHO.


View raw message