I am in favor of using a stricter-than-today SEMVER-ish approach to
our releases, not just in core but in all our releases.
To me it's really easy. Just check the issue types in JIRA and let
that decide which version number will come next. If there are only
bugs fixed then it's a patch-release,
On 20 February 2014 21:30, Dennis Lundberg dennisl.apa...@gmail.com wrote:
I am in favor of using a stricter-than-today SEMVER-ish approach to
our releases, not just in core but in all our releases.
To me it's really easy. Just check the issue types in JIRA and let
that decide which version
I think we have a bit of a disagreement about what changes should be going
into different version numbers.
To my mind, we should be using the convention that most people expect, i.e.
semver[1]-ish. I am not saying that we need to be super-strict in following
the exact semver specification, but I
Thanks for bringing this up, Stephen!
My +1 goes to backwards-compatible bug fixes (only) in a bugfix/patch
release.
If we could decide (whatever we decide) what changes goes into what sort of
release, I think that would help the community a lot. I personally think
that re-using somehting like
+1. Totally for a (nonstrict) semver Maven.
Copied from the other thread for reference:
I think you'd have a lot more confidence in moving up to a newer maven.
Enterprises will move to versions that they perceive as low risk. A true
maintenance mode with a regular predictable release
A bit of a recap:
Let's say that our goal as a group was to be very responsive to user's
bug reports.
So, we'd want to make fixes and releases, 'promptly', for some
definition of prompt.
But no one will install those releases if they are not confident that
they are, in fact, not going to have
I don't see any necessity to restrict patch releases to patches only -- as
long as any new functionality is a tiny enhancement and doesn't make
incompatibilities. Save medium/major structural changes for a new minor
version.
On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies
Agreed, if they small enhancements then I don't really want to release 4 things
issues in a patch release and then another 5. Generally I'm fine with small
enhancements, or small fixes going into patch releases, along with anything
marked @provisional as I'd rather have the experimental code in
Hello,
If you include new functionality this means that according to semver you
increase the second digit, which means conservative users will do this upgrade
step not so easy anymore (and therefore miss all future fixes).
I would rather include enhancements anyway but divert from strict
I need to remind people about the Apache rules here. Yes you can have
weekly builds. No you can't 'advertise them' in any way that is likely
to attract the attention of mere users as opposed to people engaged in
the development community. Please don't shoot me, I'm just the
messenger here.
On
So we have nightlies/weeklies and post to the dev list, that's fine.
On Feb 19, 2014, at 12:27 PM, Benson Margulies bimargul...@gmail.com wrote:
I need to remind people about the Apache rules here. Yes you can have
weekly builds. No you can't 'advertise them' in any way that is likely
to
11 matches
Mail list logo
