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
On 18 February 2014 22:49, Fred Cooke fred.co...@gmail.com wrote:
Perhaps a stupid question, however if no change goes in, and it kicks off
and gives the same gold star as the previous week, then there's no point to
releasing it, because it's the same thing, what takes care of this?
It will
You missed the point. No-change commits include:
- Clean up white space
- Fix some comments in the code base
- POM tweaks that don't affect binary output
- Light genuine bonafide refactoring that causes no actual change in
behaviour at all
There is zero point to releasing these
On 19 February 2014 10:13, Fred Cooke fred.co...@gmail.com wrote:
You missed the point. No-change commits include:
- Clean up white space
- Fix some comments in the code base
- POM tweaks that don't affect binary output
- Light genuine bonafide refactoring that causes no actual
Sorry, still working on your first email in this thread which never
explicitly stated that, only implicitly, if your read the URL linked to,
AND happened to know what state 3.2.X was in. You did indeed point this out
at a later date. My mistake. But the first email set the tone, which is
hard to
On 19 February 2014 11:05, Fred Cooke fred.co...@gmail.com wrote:
Sorry, still working on your first email in this thread which never
explicitly stated that, only implicitly, if your read the URL linked to,
AND happened to know what state 3.2.X was in.
No worries
You did indeed point this
+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
Hi,
maybe i didn't see a thing, but can someone explain me the intention of
the maven toolchain in relationship with a plugin ...
Currently i only see that it can find some kind of executable which is
configured in somekind of buildcontext...which i currently don't
understand how to
One thing it can be used for is to define a different JDK to be used (than
the one used for executing Maven itself). More info here:
http://maven.apache.org/guides/mini/guide-using-toolchains.html
/Anders
On Wed, Feb 19, 2014 at 7:12 PM, Karl Heinz Marbaise khmarba...@gmx.dewrote:
Hi,
maybe
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
Hello Karl-Heinz,
you may take a look at
https://github.com/mfriedenhagen/org.jacoco.filteringsamples. These
are some code samples for JDK5, 6, 7 and 8, which will be asmified
(decompiled) to see differences in byte code produced by different
JDKs.
This is how the maven-compiler-plugin uses the
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
sounds interesting.
WDYT folks?
On 19 February 2014 09:04, everflux g...@git.apache.org wrote:
GitHub user everflux opened a pull request:
https://github.com/apache/maven-indexer/pull/3
Update to lucene 4.6 with new API
Please note that the version is changed for local
Hi,
i just came across that the maven-acr-plugin is not listed on the page
http://maven.apache.org/plugins/index.html
The question is:
Should i create an jira issue for that and fix it afterwards or just fix
it ?
BTW: Do we have other plugins which are not listed on the page ?
Kind
Hello Mirko,
Hello Anders,
this have been the information what i have missed...
Thanks for your help.
Kind regards.
Karl-Heinz
you may take a look at
https://github.com/mfriedenhagen/org.jacoco.filteringsamples. These
are some code samples for JDK5, 6, 7 and 8, which will be asmified
Hi,
so after taken a look into SVN it looks a little bit strange to me.
The entry for the maven-acr-plugin has been added in r1087343
which is long time a go but the question is why does not appear on
the sites ?
Kind regards
Karl Heinz Marbaise
Jason, Stephen, other PMC members,
I can't really know if there is behind-the-scenes pmc-only discussion
going on, but is there any chance to get 3.2.1 released this week?
I need to do legal/IP paperwork for upcoming m2e 1.5 release by
this coming Friday, and I would really like to list Maven
Probably because not a lot of folks are using it. It's a mistake, go ahead
and add it.
Thanks,
S.
On Thursday, February 20, 2014, Karl Heinz Marbaise khmarba...@gmx.de
wrote:
Hi,
so after taken a look into SVN it looks a little bit strange to me.
The entry for the maven-acr-plugin has been
23 matches
Mail list logo
