You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by Malcolm Edgar <ma...@gmail.com> on 2009/05/04 13:45:35 UTC
Click Release Strategy
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
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
> +1, I find all the versions on the Apache site confusing and having to
> backport fixes to multiple versions is a pain.
AFAIK the Apache rules make sense, but only if they're really respected:
e.g. minor versions get *no* new features - just *serious* bug fixing.
Also there's no need to backport to "multiple" versions, just for one.
It is well possible that some Apache projects have fixes backported for
more than one version, but the main reason for that might be the JDK
support.
just my 2 cents,
A.
Re: Click Release Strategy
Posted by Bob Schellink <sa...@gmail.com>.
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 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.
+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.
regards
bob
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
>> It does not depend on JavaScript code. If the onClick event has
>> "return false"
>
>
> 'return false' is JS. Without it the link becomes clickable.
If javascript is not available, the validations don't work either, as
well as other click features. IMHO for those cases, there should
be another type of handling from Click's side.
> I don't
> really see the advantage from rendering a span vs rendering a link with
> JS in it?
I suppose than that you haven't tried the example :).
A link feels like a link - title, browser status bar change, hover
effects, etc.
> Right now you can apply the CSS from this issue to your site
> stylesheet and disabled links will look the way you want it to.
Or I can hack Abstract link to do it (the way many use Click, and
why most users build it from the source).
This is however not the point, but good defaults are (and the 80/20 rule).
>> Also it would not be "another" CSS but the official Click one - and
>> that's really included in every click based application.
>
>
> control.css is only included by Form. If you don't include a Form in
> your page the link won't be rendered as disabled unless we add
> control.css as a resource for AbstractLink.
Form and the rest of the fields - so almost all the time :).
Also something like css reset(e.g. from YUI) or some way to make click
default rendering more uniform across all browsers would be a big
advantage for Click (as these compatibility glitches waste allot of
development effort).
Re: Click Release Strategy
Posted by Bob Schellink <sa...@gmail.com>.
Adrian A. wrote:
> It does not depend on JavaScript code. If the onClick event has "return
> false"
'return false' is JS. Without it the link becomes clickable. I don't
really see the advantage from rendering a span vs rendering a link
with JS in it? Right now you can apply the CSS from this issue to your
site stylesheet and disabled links will look the way you want it to.
> Also it would not be "another" CSS but the official Click one - and
> that's really included in every click based application.
control.css is only included by Form. If you don't include a Form in
your page the link won't be rendered as disabled unless we add
control.css as a resource for AbstractLink.
bob
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
>> #6 - https://issues.apache.org/jira/browse/CLK-545
>> "Better rendering of disabled link controls"
>> No patch, but the required changes are described in the issue comment.
>> It works on the browsers Click usually supports (see the above
>> LinkDemo example too)
>
>
> I have a problem with controls which depend on JavaScript because
> sometimes (by law) you have to deal with the fact that JavaScript cannot
> be used or at least degrade gracefully.
It does not depend on JavaScript code. If the onClick event has "return
false" than the browser won't follow that link. It's just an extra to
still give the feel (not just the look) of a disabled link.
The actual solution is primitive and looks unprofessional too - no user
I asked was able to guess that "that simple text" would a "disabled link".
If you apply the patch example from #5 with this issue, you will see
what a huge difference that small improvement makes in LinksDemo.
> Also the issue suggests to use
> an external CSS file for links? So if I want to render a link with Click
> it will load an external stylesheet? Thats quite heavy for something as
> simple as a link.
We are talking about browser based applications, right?
The browser's default CSS already does a nice look for e.g. a Button
when "disabled" but not for Links.
Many use links even that "look" like buttons. However with the above
trick, Click would keep the style of the link, and add the look&feel of
a disabled element(so if it's red, it will be a "disabled red": that's
user and developer friendly.
Also it would not be "another" CSS but the official Click one - and
that's really included in every click based application.
> I've noticed quite a number of JIRA's related to adding styles to
> control which I really hope we stay away from.
>
> A more practical approach is to create site wide themes but to me this
> is outside Click's scope. See JQuery theme roller for an example:
> http://jqueryui.com/themeroller/.
This is not about themes, but about good default behavior and look.
Because the browser defaults are not ideal in many cases (or are not
compatible from browsers to browser), developers have a hard work making
it look right. Good default look and behavior saves allot of work (e.g.
just like Click already does with automapping or autobinidng or with the
nice "toString()" trick to have templates with just a $form or $table).
Theming is another issue, that might be addressed later.
BTW, jQuery themeroller produces a very heavy theming, and hard to apply
to other
elements than the standard components (the forums are full of such
problems). At first sight it's cool, but on the long run it creates more
problems than it solves :(.
>> #10 https://issues.apache.org/jira/browse/CLK-543
>> "SimpleLink control" (or improvement to ExternalLink - although
>> "SimpleLink" would be a better name.)
>
>
> We already have too many link and button controls, I'd rather we
> consolidate/remove some of them instead of adding more.
Agree (maybe because AbstractLinks shoudn't be just a "Link" - so
non-abstract and with the functionality of a "SimpleLink"?), but:
The naming is "ExternalLink" is too specific.
Important is that small functionality, independent of how we name it
(but a good name would not be bad).
Thank you,
Adrian.
Re: Click Release Strategy
Posted by Bob Schellink <sa...@gmail.com>.
Adrian A. wrote:
>
> #6 - https://issues.apache.org/jira/browse/CLK-545
> "Better rendering of disabled link controls"
> No patch, but the required changes are described in the issue comment.
> It works on the browsers Click usually supports (see the above
> LinkDemo example too)
I have a problem with controls which depend on JavaScript because
sometimes (by law) you have to deal with the fact that JavaScript
cannot be used or at least degrade gracefully. Also the issue suggests
to use an external CSS file for links? So if I want to render a link
with Click it will load an external stylesheet? Thats quite heavy for
something as simple as a link.
I've noticed quite a number of JIRA's related to adding styles to
control which I really hope we stay away from.
A more practical approach is to create site wide themes but to me this
is outside Click's scope. See JQuery theme roller for an example:
http://jqueryui.com/themeroller/.
>
> #10 https://issues.apache.org/jira/browse/CLK-543
> "SimpleLink control" (or improvement to ExternalLink - although
> "SimpleLink" would be a better name.)
We already have too many link and button controls, I'd rather we
consolidate/remove some of them instead of adding more.
bob
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
Other issues (after the #1 -> #4 were resolved):
#5 - https://issues.apache.org/jira/browse/CLK-535
"Link control to be able to render both icon an text"
Contains two patches - one for click-examples too (the example
is also practical for CLK-545)
#6 - https://issues.apache.org/jira/browse/CLK-545
"Better rendering of disabled link controls"
No patch, but the required changes are described in the issue comment.
It works on the browsers Click usually supports (see the above
LinkDemo example too)
#7 - https://issues.apache.org/jira/browse/CLK-407
"Menu improvements - more properties: enable/disable, show/hide"
No patch, but it's just a matter of adding those two properties with
getters and setters:
--------------
protected boolean disabled;
protected boolean hidden;
--------------
#8 https://issues.apache.org/jira/browse/CLK-405
"Menu improvements - allow setting the cache strategy."
Since the menu seems like the most problematic component, IMHO this
issue too should be solved to before releasing click-2.1.0, so that
the users aren't forced to hack the Menu all the time.
I suppose Bob's solution would do it.
#9 https://issues.apache.org/jira/browse/CLK-530
"Update resources for several controls"
IMHO this should be done periodically with all resources of Click,
since new browser versions bring new bugs too. Right now, those from
this issue would be a nice improvement for click-2.1.0
#10 https://issues.apache.org/jira/browse/CLK-543
"SimpleLink control" (or improvement to ExternalLink - although
"SimpleLink" would be a better name.)
Thank you,
Adrian.
P.S. IMHO several other issues (some of them mentioned by Joseph's list)
could be simply closed too - since don't count anymore or are already
implemented.
> #1 - https://issues.apache.org/jira/browse/CLK-539
> You suggested to Joseph to move the TypeConverter to a parameter. I
> already had such an implementation for myself, so I just sent the patch.
>
> #2 - https://issues.apache.org/jira/browse/CLK-536
> setRedirect() with parameters works now with this patch.
>
> (Because Click does not support something like "Global Page
> Parameter", this small patch eases this use case too - but that's
> another story).
>
> #3 - https://issues.apache.org/jira/browse/CLK-536
> The implementation was suggested by a former Click commiter.
> (Mostly in "hello world" like examples, a Table will display only one
> Entity. In commercial ones, Table columns need to span to other Entity
> properties too - this patch simplifies greatly this - without this, the
> Table would need another TransferObject - with it, it can use directly
> those Entites, and have operations on them, since the "alias" allows it)
>
> #4 - https://issues.apache.org/jira/browse/CLK-505
> Cayenne3 has changed some interfaces so the Click integration needs a
> recompile (this also takes Ashwood2 since Cayenne3 upgraded to it).
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
> I will try and work throught these next week.
Than I'll update the list with more issues that can be resolved.
> I have checked in
> the first patch.
I attached to the same issue another patch for the documentation too
(to the new one - based on DocBook).
Adrian.
Re: Click Release Strategy
Posted by Malcolm Edgar <ma...@gmail.com>.
Ok, I will try and work throught these next week. I have checked in
the first patch.
Thanks for your help.
regards Malcolm Edgar
On Sat, May 16, 2009 at 8:48 PM, Adrian A. <a....@gmail.com> wrote:
>> I would be happy to start working with you on your JIRA's items which
>> one would you like to start on?
>
> Here's a possible order - but I guess, that's not that relevant. More
> important would be to include them finally (before the source in trunk
> changes so much that a merge would not work anymore :( ).
>
> #1 - https://issues.apache.org/jira/browse/CLK-539
> You suggested to Joseph to move the TypeConverter to a parameter. I already
> had such an implementation for myself, so I just sent the patch.
>
> #2 - https://issues.apache.org/jira/browse/CLK-536
> setRedirect() with parameters works now with this patch.
>
> (Because Click does not support something like "Global Page
> Parameter", this small patch eases this use case too - but that's another
> story).
>
> #3 - https://issues.apache.org/jira/browse/CLK-536
> The implementation was suggested by a former Click commiter.
> (Mostly in "hello world" like examples, a Table will display only one
> Entity. In commercial ones, Table columns need to span to other Entity
> properties too - this patch simplifies greatly this - without this, the
> Table would need another TransferObject - with it, it can use directly those
> Entites, and have operations on them, since the "alias" allows it)
>
> #4 - https://issues.apache.org/jira/browse/CLK-505
> Cayenne3 has changed some interfaces so the Click integration needs a
> recompile (this also takes Ashwood2 since Cayenne3 upgraded to it).
>
> #5 ... many others...
>
> As you can see, applying all these patches is very very simple (it took
> more time to make them than it takes to commit and build them).
>
> Adrian.
>
>
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
> Is this the JIRA item?
>
> https://issues.apache.org/jira/browse/CLK-400
Yes.
I'm not sure why did I had this copy and paste error - with 536 instead
of 400 :( .
(I was selecting the right url, but at paste, still the old one was in
the output :( ).
Re: Click Release Strategy
Posted by Malcolm Edgar <ma...@gmail.com>.
Is this the JIRA item?
https://issues.apache.org/jira/browse/CLK-400
regards Malcolm Edgar
On Thu, May 21, 2009 at 10:44 PM, Adrian A. <a....@gmail.com> wrote:
>> This JIRA item is about page redirect parameters?
>
> It's about a very small but helpful improvement to the LinkDecorator, to be
> able to work with parameters, e.g. when "linking" elements form a table to
> pages:
> 1. the source (the column/cell in the table) has one name to get it's
> value(e.g. "toProduct.toProducer.name" for a column),
> 2. but in the target/destination(the parameter in the page - can be
> autobound) page has a different one (e.g. /detail.htm?name=myname).
>
> Without this small improvement, when using a LinkDecorator,
> the call to the target page would be, e.g.
> /detail.htm?toProduct.toProducer.name=myname
> and that's really not working with Java and the Click autobinding.
>
> I hope this helps. I can give you more examples if you need.
>
>
>> On Thu, May 21, 2009 at 10:19 PM, Adrian A. <a....@gmail.com>
>> wrote:
>>>>>
>>>>> #3 - https://issues.apache.org/jira/browse/CLK-536
>>>>> The implementation was suggested by a former Click commiter.
>>>>> (Mostly in "hello world" like examples, a Table will display only one
>>>>> Entity. In commercial ones, Table columns need to span to other Entity
>>>>> properties too - this patch simplifies greatly this - without this, the
>>>>> Table would need another TransferObject - with it, it can use directly
>>>>> those
>>>>> Entites, and have operations on them, since the "alias" allows it)
>>>>
>>>> Which JIRA item are you referring to here?
>>>
>>> CLK-536 is the issue. And there's the patch too.
>>> How to implement it, was suggested at the link inside the issue.
>>> (and other posts on the list around that time)
>
>
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
> This JIRA item is about page redirect parameters?
It's about a very small but helpful improvement to the LinkDecorator, to
be able to work with parameters, e.g. when "linking" elements form a
table to pages:
1. the source (the column/cell in the table) has one name to get it's
value(e.g. "toProduct.toProducer.name" for a column),
2. but in the target/destination(the parameter in the page - can be
autobound) page has a different one (e.g. /detail.htm?name=myname).
Without this small improvement, when using a LinkDecorator,
the call to the target page would be, e.g.
/detail.htm?toProduct.toProducer.name=myname
and that's really not working with Java and the Click autobinding.
I hope this helps. I can give you more examples if you need.
> On Thu, May 21, 2009 at 10:19 PM, Adrian A. <a....@gmail.com> wrote:
>>>> #3 - https://issues.apache.org/jira/browse/CLK-536
>>>> The implementation was suggested by a former Click commiter.
>>>> (Mostly in "hello world" like examples, a Table will display only one
>>>> Entity. In commercial ones, Table columns need to span to other Entity
>>>> properties too - this patch simplifies greatly this - without this, the
>>>> Table would need another TransferObject - with it, it can use directly
>>>> those
>>>> Entites, and have operations on them, since the "alias" allows it)
>>> Which JIRA item are you referring to here?
>> CLK-536 is the issue. And there's the patch too.
>> How to implement it, was suggested at the link inside the issue.
>> (and other posts on the list around that time)
Re: Click Release Strategy
Posted by Malcolm Edgar <ma...@gmail.com>.
This JIRA item is about page redirect parameters?
regards Malcolm Edgar
On Thu, May 21, 2009 at 10:19 PM, Adrian A. <a....@gmail.com> wrote:
>
>>> #3 - https://issues.apache.org/jira/browse/CLK-536
>>> The implementation was suggested by a former Click commiter.
>>> (Mostly in "hello world" like examples, a Table will display only one
>>> Entity. In commercial ones, Table columns need to span to other Entity
>>> properties too - this patch simplifies greatly this - without this, the
>>> Table would need another TransferObject - with it, it can use directly
>>> those
>>> Entites, and have operations on them, since the "alias" allows it)
>>
>> Which JIRA item are you referring to here?
>
> CLK-536 is the issue. And there's the patch too.
> How to implement it, was suggested at the link inside the issue.
> (and other posts on the list around that time)
>
>
>
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
>> #3 - https://issues.apache.org/jira/browse/CLK-536
>> The implementation was suggested by a former Click commiter.
>> (Mostly in "hello world" like examples, a Table will display only one
>> Entity. In commercial ones, Table columns need to span to other Entity
>> properties too - this patch simplifies greatly this - without this, the
>> Table would need another TransferObject - with it, it can use directly those
>> Entites, and have operations on them, since the "alias" allows it)
>
> Which JIRA item are you referring to here?
CLK-536 is the issue. And there's the patch too.
How to implement it, was suggested at the link inside the issue.
(and other posts on the list around that time)
Re: Click Release Strategy
Posted by Malcolm Edgar <ma...@gmail.com>.
On Sat, May 16, 2009 at 8:48 PM, Adrian A. <a....@gmail.com> wrote:
>> I would be happy to start working with you on your JIRA's items which
>> one would you like to start on?
>
> Here's a possible order - but I guess, that's not that relevant. More
> important would be to include them finally (before the source in trunk
> changes so much that a merge would not work anymore :( ).
>
> #1 - https://issues.apache.org/jira/browse/CLK-539
> You suggested to Joseph to move the TypeConverter to a parameter. I already
> had such an implementation for myself, so I just sent the patch.
>
> #2 - https://issues.apache.org/jira/browse/CLK-536
> setRedirect() with parameters works now with this patch.
>
> (Because Click does not support something like "Global Page
> Parameter", this small patch eases this use case too - but that's another
> story).
>
> #3 - https://issues.apache.org/jira/browse/CLK-536
> The implementation was suggested by a former Click commiter.
> (Mostly in "hello world" like examples, a Table will display only one
> Entity. In commercial ones, Table columns need to span to other Entity
> properties too - this patch simplifies greatly this - without this, the
> Table would need another TransferObject - with it, it can use directly those
> Entites, and have operations on them, since the "alias" allows it)
Which JIRA item are you referring to here?
> #4 - https://issues.apache.org/jira/browse/CLK-505
> Cayenne3 has changed some interfaces so the Click integration needs a
> recompile (this also takes Ashwood2 since Cayenne3 upgraded to it).
>
> #5 ... many others...
>
> As you can see, applying all these patches is very very simple (it took
> more time to make them than it takes to commit and build them).
>
> Adrian.
>
>
thanks Malcolm Edgar
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
> I would be happy to start working with you on your JIRA's items which
> one would you like to start on?
Here's a possible order - but I guess, that's not that relevant. More
important would be to include them finally (before the source in trunk
changes so much that a merge would not work anymore :( ).
#1 - https://issues.apache.org/jira/browse/CLK-539
You suggested to Joseph to move the TypeConverter to a parameter. I
already had such an implementation for myself, so I just sent the patch.
#2 - https://issues.apache.org/jira/browse/CLK-536
setRedirect() with parameters works now with this patch.
(Because Click does not support something like "Global Page
Parameter", this small patch eases this use case too - but that's
another story).
#3 - https://issues.apache.org/jira/browse/CLK-536
The implementation was suggested by a former Click commiter.
(Mostly in "hello world" like examples, a Table will display only one
Entity. In commercial ones, Table columns need to span to other Entity
properties too - this patch simplifies greatly this - without this, the
Table would need another TransferObject - with it, it can use directly
those Entites, and have operations on them, since the "alias" allows it)
#4 - https://issues.apache.org/jira/browse/CLK-505
Cayenne3 has changed some interfaces so the Click integration needs a
recompile (this also takes Ashwood2 since Cayenne3 upgraded to it).
#5 ... many others...
As you can see, applying all these patches is very very simple (it took
more time to make them than it takes to commit and build them).
Adrian.
Re: Click Release Strategy
Posted by Malcolm Edgar <ma...@gmail.com>.
Hi Adrian,
I would be happy to start working with you on your JIRA's items which
one would you like to start on?
regards Malcolm Edgar
On Tue, May 12, 2009 at 11:01 PM, Adrian A. <a....@gmail.com> wrote:
>> 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 Apache.org 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.
>
> A.
>
>
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
> 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 Apache.org 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.
A.
Re: Click Release Strategy
Posted by Malcolm Edgar <ma...@gmail.com>.
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. <a....@gmail.com> wrote:
>
>> 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.
>
> -1 for this.
> Click already migrated to Apache.org and it should reflect this on
> click.sf.net too.
> I think a much better approach would be the other way around:
> 1. http://click.sf.net 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
this.
* 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
Re: Click Release Strategy
Posted by "Adrian A." <a....@gmail.com>.
> 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.
-1 for this.
Click already migrated to Apache.org and it should reflect this on
click.sf.net too.
I think a much better approach would be the other way around:
1. http://click.sf.net 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.
> 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 :) ?
> 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.