Hi team,
I think it is worth clarifying here what a patch release is for. Perhaps I
didn't articulate this as well as I could of when I proposed the vote.
The use case of a patch release is where there are problems (bugs) with the
software. In this situation I often see a couple of things happen re. a project
depending on the software:
* they patch their own classes which take higher precedence on the class path;
and/or
* they fork their own releases.
Neither of these paths are great in terms of the overall value in making
software open source in the first place - we want people to actively contribute
patches and have them turned around fast in the spirit of ensuring that quality
is optimal. I believe that the gates to patching release should be kept to an
absolute minimum.
Let's not forget then the reason for a patch release - there are bugs and the
existing release is sub-optimal. There are *no* changes to the software's
public API.
Lastly, why also pollute this list with votes around patches that are just
noise? If we make posts to the lists more significant then more people will pay
attention to them.
Thanks - I hope that you change your minds! :-)
Kind regards,
Christopher
On 17/05/2012, at 7:48 AM, Jesse McConnell wrote:
> +1 for minor point releases, you shouldn't be adding new plugin
> breaking functionality in a point release anyway
>
> my 2c,
> jesse
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
