On 24.10.2014 10:11, Jürgen Schmidt wrote:
> On 24/10/14 10:00, RA Stehmann wrote:
>> On 23.10.2014 18:16, Rob Weir wrote:
>>> A short term goal, in addition to whatever 5.0 discussions we want to have.
>>>
>>> Let's try for a 4.1.2 release containing:
>>>
>>> 1) Whatever new languages/language updates we have, including of
>>> course dictionary updates.
>>>
>>> 2) Fixes for any critical bugs, especially any introduced in AOO
>>> 4.1.1.  Do we know yet which bugs these are?   Do we have a short list
>>> of the most critical ones?
>>>
>>> 3) Patches merged in from new dev volunteers.
>>>
>>> I think #3 is extremely important here.  Although not as evident to
>>> users, these small fixes and small enhancements reflect wins in the
>>> community.   We've had many new dev volunteers in the past few months
>>> working on "easy fixes".   Let's try to help them get their good work
>>> into the hands of users via a release, and give us all the good
>>> feeling that comes from shipping code.
>>>
>>> So this might be a slower release, since we're focused on new
>>> volunteers and mentoring them takes time.   But I think this is a
>>> worthwhile investment in the community.
>>>
>>> What do you think?
>>>
>>
>> It's ok for an exceptional case, but normally we should follow the
>> established release schema: x.y.0 and than x.y.1 and than either x+1.0.0
>> or x.y+1.0.
>>
>> It was communicated and is well known by the users, and we should
>> demonstrate reliableness.
>>
>> I don`t like a x.y.5 or higher version for AOO. I love distinction ;-).
> 
> Let's see the logic behind the version numbers
> 
> <major>.<minor>.<micro>
> 
> <major>: huge release with visible changes and new features including
> incompatible API changes if necessary. Translation updates are most
> often necessary to address the UI visible changes.
> 
> <minor>: smaller improvements of features that don't need any
> translation. And of course any kind of bug fixes.
> 
> <micro>: only selected bug fixes and most often only critical ones. This
> includes any potential security issues.
> 
> Keeping this in mind a 4.2 would probably make more sense but will we
> have enough fixes and minor improvements in place?
> 

I'm with you and Rob in this special case. Rules need exceptions.

But we have to communicate this exception very well and should
afterwards follow our approved schema again.

Kind regards
Michael



Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to