5 at 03:14, Elliotte Rusty Harold
wrote:
> On Sun, Mar 16, 2025 at 1:55 PM Fred Cooke wrote:
> >
> > You are *severely* downplaying what tiles are used for - it's not "parent
> > duplication avoidance" it's an entirely new paradigm and when fully
>
rocesses pom.xml
> > files. Doing this requires a truly compelling reason, and avoiding
> > duplication in parent poms isn't it.
> >
> > It's possible that what you're trying to achieve could be equally well
> > achieved by appropriate use of XInclude, t
oms isn't it.
> >
> > It's possible that what you're trying to achieve could be equally well
> > achieved by appropriate use of XInclude, though Maven's borked
> > namespace handling might prevent that.
> >
> > On Sun, Mar 16, 2025 at 1:28 PM Fred
propriate use of XInclude, though Maven's borked
> namespace handling might prevent that.
>
> On Sun, Mar 16, 2025 at 1:28 PM Fred Cooke wrote:
> >
> > Why not simply adopt the existing widely used tile system - but not
> require
> > the plugin anymore
e, blaze, buck, google3, and probably other systems I'm not
> familiar with. However any such effort should be its own project, and
> not part of Maven. Maven itself is too restricted by backwards
> compatibility.
>
> On Sun, Mar 16, 2025 at 8:40 AM Fred Cooke wrote:
> >
>
I'd like to revive this discussion on tiles and possible alternatives.
I'll say it bluntly: Maven without tiles or an equivalent is not something
I want to use. And yet there's nothing else that comes close, either.
I've been using Maven since 2006 (2, then 3) and tiles since 2017,
intensely sinc
Excellent write up, Rusty, thank you. Peer review is always a good thing,
period. It's surprising to me that anyone is allowed to push to any
component directly without the opportunity to vet commit quality and other
things that are hard to automate into the build. Even the very best
sometimes make
ew is the tool you want to provision Maven?
> - Are you aware of SDKMAN (https://sdkman.io/) for example, that is able
> to
> do exactly what you need, out of the box?
>
> But in general, I am completely aligned with Karl, try latest (as you
> noticed, soon 3.8.3)
>
> HTH
>
larious.
Cheers,
Fred.
On Fri, 1 Oct 2021 at 09:11, Karl Heinz Marbaise wrote:
> Hi,
>
> On 30.09.21 15:49, Fred Cooke wrote:
> > Hi all,
> >
> > We've hit an issue with maven 3.8.2 which a lot of our clients use on
> macs
> > through Brew and although
Hi all,
We've hit an issue with maven 3.8.2 which a lot of our clients use on macs
through Brew and although brew supports the latest 3.8, 3.5, 3.3, 3.2
versions it does not support 3.8.1 which doesn't have the regression and
does not have 3.6 which was also fine for our purposes.
I'm not sure if
;mvn wrapper') and a new plugin('maven-wrapper-plugin)
> - improved commandline options when working with multimodule projects.
> - jansi based console output improvements
>
> This is just a short summary of the release[1], but it should give you an
> idea why this version sh
Is there somewhere where I can read about the rationale behind the first
major version bump since I learned M2 15 years ago and what's changed in a
positive but breaking fashion that warranted that bump?
Just the 4 sounds exciting without any context. I hope the context lives up
to it, but 3 has b
Yeah, it still gets a bit of traffic.
On Tue, 31 Mar 2020 at 00:43, Elliotte Rusty Harold
wrote:
> A lot of our docs and READMEs talk about the IRC channel. E.g.
>
> #Maven IRC channel on freenode.org
>
> Is this still in use? Or should I remove this from the docs where I
> find it and perhaps
The process is done through IRC, there will be a help page on freenode
somewhere, search register or similar.
You connect with desired nickname, and then send commands to nickserv to
sort it out.
On 18 August 2018 at 04:47, Christian Stein wrote:
> On Fri, Aug 17, 2018 at 2:41 PM Fred Co
Yes, create an account, spam attack = +r set on most channels and
registration required to enter. Hope that helps.
On 18 August 2018 at 00:37, Christian Stein wrote:
> Hi Maven-Devs,
>
> tried to join #maven-dev via http://webchat.freenode.net but it
> does not work like it used to do. I guess,
3.5.3 as per subject and list or 3.5.2 as per opening sentence? Guessing
the former.
On 9 March 2018 at 01:31, Stephen Connolly wrote:
> The Apache Maven team is pleased to announce the release of the Apache
> Maven 3.5.2
>
> You can download the appropriate sources etc. from the download page
>
Looks like I'm just plain wrong (and happy about it). I'm not sure where
that memory came from. Perhaps maven 2 some time ago, though it felt fresh
in my mind. Apologies for the noise! :-(
On 11 January 2018 at 11:22, Hervé BOUTEMY wrote:
> Le mercredi 10 janvier 2018, 10:21:35 CET Andreas Sewe
Re versions, I know the background on it, but it annoys me that maven can't
handle 4 part versions, 1.2.3.4 as sometimes it's handy to do a patch level
that deep. Lots of messed up software in the world :-)
Format should be N[.N as many times as needed][optional hyphen and
qualifier of some sort]
I'll throw my 2c in here, too:
Java 9 runtime forces me to rewrite parts of my application because
non-root thread priority control is no longer available. Plenty of people
have relied on lines like this to achieve their desired behaviour:
java -jar -Xms128m -Xmx1024m *-XX:ThreadPriorityPolicy=42
Yes, agreed, 30 is a lot, but if you have N artifacts in a dir running
sha1sum dir/* and pasting the result raw into the email is not difficult.
Less so than formatting the two, probably.
On 8 April 2017 at 09:13, Stephen Connolly
wrote:
> On 7 April 2017 at 22:10, Fred Cooke wr
Thanks for all of your hard work on this, much appreciated!
A little feedback for 3.5.1 (not helping with 3.5.0): checksums for the
binaries too, not just the source.
That's it. :-)
On 8 April 2017 at 09:05, Stephen Connolly
wrote:
> 24. Publish the website with https://cms.apache.org/maven/pu
+1 non binding, built my main app without drama, and the rest of my
personal projects are simpler
On 5 April 2017 at 09:37, Tibor Digana wrote:
> +1 (binding)
>
> On Tue, Apr 4, 2017 at 12:14 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Hi,
> >
> > We solved 86 issues:
s due diligence and a wise thing
to do in a dynamic code base.
On 20 March 2017 at 20:15, Stephen Connolly wrote:
> On Mon 20 Mar 2017 at 00:44, Fred Cooke wrote:
>
> > Sounds like the solution is for people to use a different remote that you
> > don't feel personally re
hat's rubbish. A merge, or a rebase, is
a human operation, even when the tool can do it "cleanly"/automatically. To
ignore this is to introduce subtle issues and breakages.
On 20 March 2017 at 10:20, Stephen Connolly wrote:
> On Sun 19 Mar 2017 at 20:05, Fred Cooke wrote:
>
No need to cherry-pick, that should be a rare operation.
Clean up the branch and prepare it for a fast forward with high quality
commits, then just push it when it's ready and passes scrutiny and tests.
+1 on ugly masters. Last time I looked at the docker project the displayed
history showed 15 o
How are branches noisy? Promiscuous automated emails or some such?
Surely you don't need to look at all branches unless you've been asked to
pre-review something prior to fast-forward? Just the ones you're interested
in?
Naming scheme sounds sensible, however unless everyone is constantly
rebasin
On Wed, Jan 18, 2017 at 6:01 AM, Fred Cooke wrote:
>
> > By revert do you mean reset --hard or keep the full history and rest the
> > contents then re commit and verify with a diff to that hash?
> >
> > Or did you mean revert, each commit, in reverse order, back to that
By revert do you mean reset --hard or keep the full history and rest the
contents then re commit and verify with a diff to that hash?
Or did you mean revert, each commit, in reverse order, back to that base?
On Wed, Jan 18, 2017 at 5:43 PM, Tibor Digana
wrote:
> Hi,
>
> We have messed up Sure
> > once your push has succeeded
> >
> > git push origin :BRANCH
> >
> >
> > On 16 January 2017 at 08:51, Christian Schulte wrote:
> >
> >> Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> >> > No, not correct in my books.
> >> >
On 16 January 2017 at 08:51, Christian Schulte wrote:
>
> > Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> > > No, not correct in my books.
> > >
> > > git checkout BRANCH # Assuming it's local already
> > > git fetch upstream # risk free, unlike pull
from hash is not what I thought, then I back it out again. Though that's
yet to happen, so I'll save the key strokes and use my alias "git force".
On Mon, Jan 16, 2017 at 9:51 PM, Christian Schulte wrote:
> Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> > No, not co
After verifying no one has pushed to it
# create pull request/email someone/communicate your intention to have it
merged
^ correct in my books, others may differ.
On Mon, Jan 16, 2017 at 8:52 PM, Christian Schulte wrote:
> Am 16.01.2017 um 08:27 schrieb Fred Cooke:
> > Rebase is the
Rebase is the only clean way forward for small projects in which people
step on each others toes.
Merge commits are difficult to comprehend for some developers, leading to
errors. Avoiding them is beneficial.
On Mon, Jan 16, 2017 at 8:23 PM, Hervé BOUTEMY
wrote:
> do we want to keep such merge
Christian, some (potentially unwelcome) advice: Learn to use rebase, learn
to fetch, never pull, and review your changes in their new context before
pushing them.
Whether you take the advice, or not, this is how I ensure that my changes
are clean and focused and coherent, every time.
Pull is a bl
Commons lang could commit to providing patch releases/bug fixes in a
maintenance series of the existing line
for that purpose. Then it'd be totally fine to do whatever they liked in
the new version with major incremented.
On Mon, Sep 26, 2016 at 3:20 AM, Robert Scholte
wrote:
> On Sun, 25 Sep 20
Yes, presumably to be consumed in another build, right? :-)
On Tue, Aug 30, 2016 at 10:45 AM, Christian Schulte wrote:
> Am 08/30/16 um 00:33 schrieb Fred Cooke:
> > I fail to see how any such flattening can do away with interpolation.
> Your
> > typical nonlib project has sa
I fail to see how any such flattening can do away with interpolation. Your
typical nonlib project has say 5-100 deps, each of which would have a flat
tree that needs to be compared with and resolved against the others. I can
see it speeding things up due to having all of the information for just th
hat is to say, don't forget about non-central deployments. I
suppose if there's a way to always deploy pom.xml.build through some plugin
or configuration or some such, then that's fine with me.
On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY
wrote:
> Le mercredi 24 août 2016 18:41
.xml.build or some such? I think
so, but I haven't thought deeply about it aside from reading this thread.
On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY
wrote:
> Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> > That should have separation between builder Pom and consumer Pom.
That should have separation between builder Pom and consumer Pom. For
packaging=pom we deploy the builder Pom using classifier=build
*for all other packaging a we do not deploy the builder Pom*.
I don't like the sound of this. The deployed artefacts should include the
exact POM in use to build the
Someone nailed it when they said it'd be two big decisions, one for JRE one
for MVN.
But here's the reality: People are just going to grab and use "the latest",
whatever it is.
What does that mean? We'll probably start seeing dependencies we can't
consume, but want to, and otherwise could.
A goo
Something doesn't have to be in Java to be universal (as SLF4J really is),
and conversely, something being in Java doesn't make the world instantly
catch up (eg YodaTime vs J8+).
Adding the nop logger as a dep seems like the wrong thing to do and will
(IIRC) cause a warning/error at runtime if the
Clearly it's going to matter to him if Maven fails to provide and it
doesn't work. Some sort of dependency isolation not right somewhere?
Something seems to be going on. You're right, but he's seeing behaviour
that indicates something is amiss.
On Mon, Aug 15, 2016 at 6:37 PM, Michael Osipov wrot
The solution is to not push directly, and to seek peer review even if
you're the king of the hill. Once pushed to a public upstream a commit
should pretty much never be touched.
What was the impact of the encoding being wrong? I haven't yet understood
the actual problem.
On Sun, Aug 7, 2016 at 6:
Got it! Thanks. The dependency without [] needs to exist, but may not end
up being used due to conflicts. Fair enough. :-)
On Sat, Aug 6, 2016 at 3:24 PM, Christian Schulte wrote:
> Am 08/06/16 um 05:15 schrieb Christian Schulte:
> > It just takes the highest version the version range resolver r
A parent, I thought, used to be equivalent to [], ie, hard requirement. A
dependency without [] is NOT a hard requirement, simply advisory. So yeah,
they're different, or were. I wonder what semantics the ranged parents
behaviour has for a simple backward compatible (or not) plain version?
Implicit
I'm surprised the transitive dependency to that parent succeeds, unless
it's ranged.
For the others, in order to determine the dependency tree, and thus any
transitive dependencies, and so on, the entire pom needs to be present. A
parent is part of that. If the parent is of a fixed version (all th
I take that back. In a single blow, you changed the entire file! Why?
Because since that file was created on Christmas eve 2015, it has had
broken line endings. Fix up the line endings and move on.
On Mon, May 30, 2016 at 4:20 PM, Fred Cooke wrote:
> I cloned it, assuming you're talki
I cloned it, assuming you're talking about the linked hash, which is the
tip/head of master, then the diff shown is correct, you moved the package
declaration around under the auspices of "investigating". Your change must
be in an earlier commit. I looked at a few, but gave up.
On Mon, May 30, 201
"You can run maven with Java 8 right now, so it is not a change in any way
for those users."
This equates to ruling out developers who are forced to use older JDKs/JREs
if you look at it the other way.
"I agree that jumping to Java 8 would be unwise. I think we can wait until
4.x. Don’t get me wr
My 2c:
Our shop has all of the infrastructure on Ubuntu (for better or worse) and
no LTS Ubuntu version exists with Java 8.
So for now we (and anyone else using Ubuntu) are stuck with a few options:
1) stay with 12.04/14.04 and J7
2) backport J8 to 14.04 and/or use a PPA
3) use a non-LTS stable
Compare this original version:
[ERROR] Failed to execute goal on project emerge-monolithic-services: Could
not resolve dependencies for project
nz.co.company.emerge:emerge-monolithic-services:jar:40.166-SNAPSHOT: Failed
to collect dependencies for
nz.co.company.emerge:emerge-monolithic-services:ja
end on.
>
> Am Tue, 27 Oct 2015 14:03:01 +1300
> schrieb Fred Cooke :
>
> > False, you've locked to a specific version of a thing which depends on
> > ranges. This does not lock down those ranges, as it doesn't have
> > enough information to do that.
> >
r dependencies will also have no
> ranges and you do not need to lock them down transitively.
>
> BTW: I really think tis is a topic for the maven-user list.
>
> Gruss
> Bernd
>
> Am Tue, 27
> Oct 2015 11:21:09 +1300 schrieb Fred Cooke :
>
> > In our case, we don&
rting of potential issue too there)
>
> On Monday 26 October 2015, Fred Cooke wrote:
>
> > In our case, we don't want the original range back exactly, we want the
> > current version of that, ie, higher lower bound to currently released
> > things.
> >
> >
In our case, we don't want the original range back exactly, we want the
current version of that, ie, higher lower bound to currently released
things.
Do not forget the transient ranges that need to be locked in our modified
pom, either. Without this any tooling would be severely limited in use.
F
There is a plugin by a friend of a friend (don't ask me what it's called)
that writes out a de-ranged pom.xml as part of the build, in the event that
you need to reproduce a build, eg, branching from a tag for a production
fix, you swap in the tag, drop in the pom, make the change down stream as
re
Benson, I'm curious as to what you did, and also how it broke both for Git
users and other users. Any links/refs/bugs/emails/etc to read?
Was it just a case of leveraging features only available in very new
versions? A data point if so:
This sid laptop 2.1.3
My wheezy server 1.7.10.4
Work ucuntu
Some of the issues are mine. I'm pretty sure that at some point I realised
that to get it working properly for my use case would require forking it to
a privately released version. I guess now that it's mostly or all in git,
that's feasible. The conflicting requirements across SCMs, the highly
vari
Not that I know of, you seem to be in the right one. :-)
On Sat, Jun 13, 2015 at 10:23 PM, Robert Scholte
wrote:
> It seems less crowded on the IRC @ FreeNode (Europe) compared to IRC @
> codehaus.
> Did I miss some rooms?
>
> Robert
>
>
> Op Mon, 11 May 2015 18:16:52 +0200 schreef Jason van Zyl
ian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14574303
> explain the issue better?
>
> On 5 June 2015 at 11:05, Fred Cooke wrote:
>
> > Your tar file is polluted with ._ stuff that ends up laying around the
> > place. Aside from that:
> >
> >
Your tar file is polluted with ._ stuff that ends up laying around the
place. Aside from that:
3.1.1 succeeds.
3.3.3 fails
The description of what is wrong/your expectation could be better.
I guess I would expect it to fail, but fail because relative path POM
version doesn't match that specified
Yep, that's getting pretty deep! If the clone(s where's the s?) has
been done poorly (monolithically or otherwise brokenly) then the only
sensible option is to do it again. The right approach is the slow one, per
slice, otherwise the tags don't make sense. Trying to do this after the
fact from
Git can generate normal patches that you can simply apply and commit after
testing. Or you could have a Git-SVN repo of your own setup, fetch the git
commits, cherry pick hem into your SVN based tree, and dcommit them back
up. I use Git-SVN every day at work. It's either that or kill myself as SVN
+1, SVN fans should not be involved in these decisions at all, they'll just
get it totally wrong.
On Mon, Jun 1, 2015 at 8:08 PM, Arnaud Héritier wrote:
> For me it should be one per plugin, shared component.
> Everything which has its own release lifecycle must have its own repo
>
> On Mon, Jun
+1 from me, too! Well said.
On Sun, May 31, 2015 at 6:09 AM, Michael Osipov wrote:
> Am 2015-05-30 um 17:17 schrieb Jason van Zyl:
>
>> If they have truly separate development cycles, then I think it best to
>> try and move toward meaningful (semantic) versioning for each component.
>> Which mea
Yes, been lurking there for years anyway, and it's usually bigger, but the
topic needs to be updated to not say "go to codehaus irc", last time I
looked, anyway.
On Mon, May 11, 2015 at 8:41 AM, Robert Scholte
wrote:
> Hi,
>
> Up until now the official IRC rooms were #maven and #maven-dev @
> ir
Well, if you created it, then a personal thank you from me for that. I
would never use it for normal web stuff, but for the autogenerated stuff
like PMD, checkstyle, findbugs, cross ref code, javadocs, etc etc it's
GREAT at release time to give you a reference of what was. Or during dev,
when one f
is well defined within their context,
you're doing well. For example, your long lived release branches.
On Mon, Feb 23, 2015 at 5:09 PM, Chris Graham wrote:
> On Mon, Feb 23, 2015 at 8:42 AM, Fred Cooke wrote:
>
> >
> > I'd also love to hear that no one is trying to re
It's worth pointing out that if you just run the two part version in the
first place you are doing the same thing. IE, internally maven's versions
are always x.y.z even if you only specify x.y thus if you have 2.6 and
you're doing SemVer (2+, 1 sucked), then it'll behave correctly. Add the
patches
mers in the past that went
> through all sorts of contortions to collect all the various snapshot
> versions for a release to mimc something like CD but it's certainly not
> ideal.
>
> On Dec 14, 2014, at 8:44 PM, Fred Cooke wrote:
>
> > Thank /***, finally some mov
Thank /***, finally some movement in the right direction! :-D
Please also try to remember that EVERY single one of your "users" is a
*developer* and should comprehend that a version is an arbitrary label on a
piece of software to be used to uniquely identify it. If not, they should
be educated
There will still be a copy around, get hold of the original and push it
back up. Hooks should be setup to prevent tag deletion...
On Tue, Sep 16, 2014 at 8:40 AM, Robert Scholte
wrote:
> Ouch?!
>
> Op Mon, 15 Sep 2014 03:44:29 +0200 schreef :
>
> Repository: maven-wagon
>> Updated Tags: refs/
Leave SVN alone, it's only a matter of time before it's permanently retired
in it's entirety, right?
On Tue, Jul 29, 2014 at 12:58 PM, Brett Porter wrote:
> Hi,
>
> About a year ago, the EOL banner was added for Maven 1.x. Today I saw
> there was a still a maven-1.x link in the navigation from
A minimum is just that, a minimum! My repo is 600 meg, but I have a stack
of *dependencies* in there... A minimum should not include *user*
dependency guesswork, it should only include what a default hello-world
project with NO deps outside the default near-empty pom produces when run
through most
+
+org.apache.maven.wagon
+wagon-ssh-external
+${extension.version.wagon}
+
It was SSH settings that were not being respected. Things like ports and
ssh hosts vs DNS lookups, etc.
There were other issues with multi-module-par
The entire SCM interface is very SVN-centric IMO. I raised a number of git
related m-rel-p issues some time ago, but have been busy moving countries
and more in the mean time. I doubt there has been progress on them, though.
One pretty much required a core change to Maven (perhaps something for
4.0
shake :-)
On Thu, Feb 20, 2014 at 12:00 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On 19 February 2014 10:13, Fred Cooke wrote:
>
> > You missed the point. No-change commits include:
> >
> >- Clean up white space
> >- Fix some co
these things.
Fred.
On Wed, Feb 19, 2014 at 10:46 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On 18 February 2014 22:49, Fred Cooke wrote:
>
> > Perhaps a stupid question, however if no change goes in, and it kicks off
> > and gives the same gold st
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? Just
the human going "well, actually there were no commits, so this email is
spur
on is on ASF
> > (canonical)
> > > git
> > > repo [1]
> > > at the moment, everything seems flat
> > > IMHO, some git expert should work with infra to make it more structured
> > >
> > > Regards,
> > >
> > > Hervé
> > >
>
I have my private git repo setup in a nested way. No reason you couldn't do
that the same for this.
baseurl/org/apache/mvn/core/componentA.git
etc.
Unsure if this addresses your concerns or not, but it's certainly neat and
tidy at the server end, and the user can duplicate the path structure the
Great posts, Jason! There are so many reasons to dump SVN, but controlled
branch sharing and personal work flow are big ones for me, too. I have a
dozen or more local branches of my project, too, and like you, I rebase
against what I publish until they're ready, then publish them, and rebase
the ot
The SVN repo should probably be retained anyway, just in RO format, and
with a new URL that indicates it shouldn't be used. You can try to retain
all history, but it's never quite in the same form, really. Perhaps no one
cares, though?
+1 for decompose into individual repos.
Fred.
PS, perhaps on
I like you more and more! :-)
On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl wrote:
> Can we start the process of converting everything to Git. I don't really
> see any benefit in using Subversion any longer.
>
> If so then we should just get together for a day and convert them and then
> get i
+1 list looks good.
Beware of jgit and symlinks, though, you can end up with a lot of disk and
cpu churn because of it if not careful.
On Thu, Oct 24, 2013 at 5:35 AM, Olivier Lamy wrote:
> Hi,
> We fixed 9 issues. The new feature is the jgit provider (based on jgit).
> Details:
> http://jira.
+1 too, 1.5 is dead for me.
On Mon, Oct 7, 2013 at 8:12 PM, Dennis Lundberg wrote:
> +1 to 1.6 for 3.2
>
> On Sat, Oct 5, 2013 at 5:03 AM, Jason van Zyl wrote:
> > Given the vote we had about releases after September does anyone mind if
> I update the source/target levels to 1.6 for the core?
>
Congratulations, Jason! :-)
On Fri, Oct 4, 2013 at 10:56 PM, Jason van Zyl wrote:
> Hi!
>
> The Apache Maven Team is pleased to announce the release of 3.1.1
>
> The release notes can be found here:
> http://maven.apache.org/docs/3.1.1/release-notes.html
>
> The release can be downloaded from:
+1 even if I'm late to the epic party. Love the sebbaliser, great work, and
sense of humour, Jason! Dislike his lack of enthusiasm for the name. I'd
have bragged about it for years if you'd called it the fredaliser :-)
Unfortunately I am too busy to continue nagging. Good on sebb for picking
up the
Fair call.
On Mon, Sep 16, 2013 at 1:39 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On 16 September 2013 12:26, Fred Cooke wrote:
>
> > Version ranges are extremely useful for this case: lib 0.2.4 >> 0.3.0 non
> > inclusive where lib has a g
Version ranges are extremely useful for this case: lib 0.2.4 >> 0.3.0 non
inclusive where lib has a guaranteed stable API with only non-breaking bug
fixes and additions. There are other uses, too. I sincerely hope it's never
dropped or broken.
On Mon, Sep 16, 2013 at 10:09 AM, Stephen Connolly <
> work on core to continue without having to coordinate a "nobody commit to
> master while vote in play" policy which seems completely against how one
> should use GIT
> >
> > Sent from my iPhone
> >
> > On 15 Sep 2013, at 12:30, Fred Cooke wrote:
> &
s.
> >
> > For now, I'd prefer reusing versions and no gaps. I don't mind deleting
> > tags, otherwise I'd prefer the usage of RCx during votes.
> >
> > Robert
> >
> > Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
> > fred.c
* we would allow gaps, we should also introduce LTS releases.
>
> For now, I'd prefer reusing versions and no gaps. I don't mind deleting
> tags, otherwise I'd prefer the usage of RCx during votes.
>
> Robert
>
> Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred
aps. Call me provincial, but I'd like to do what we've always done since
> the inception of the project unless there is a compelling reason to do
> otherwise.
>
> On Sep 14, 2013, at 7:48 PM, Fred Cooke wrote:
>
> > Jason, PLEASE understand that you do NOT have a single
x27;s mainly because the maintenance and housekeeping costs on
> > >> the JIRA front and others which use the version nr as reference.
> > >>>
> > >>>
> > >>> Imagine that you would need to move all the JIRA tickets which got
> > >> marked as fixed
would be broken - or would need to get maintained manually.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > - Original Message -
> >> From: Fred Cooke
> >> To: Maven Developers List
> >> Cc:
> >> Sent: Saturda
- Original Message -
> > >> From: Arnaud Héritier
> > >> To: Maven Developers List
> > >> Cc:
> > >> Sent: Saturday, 14 September 2013, 19:45
> > >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> > >>
> >
tags would be allowed on this repo. Might be a way to tackle this on
> ASF hardware without forcing people to use another repo hosting.
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
> > From: Fred Cooke
> > To: Maven Developers List
>
practice too. I'm using it also at work and we are doing our
> >> releases on dedicated branches.
> >>
> >> -
> >> Arnaud
> >>
> >> Le 14 sept. 2013 à 19:30, Fred Cooke a écrit :
> >>
> >>> You're i
1 - 100 of 184 matches
Mail list logo
