I'm late to the party here, tonight, but can we clarify what a multi
project release is? is it a multi module release? or something more like
continuous release?
As for needs release how can this be automatically determined? This seems
fundamentally human to me? Or do you simply mean dependency
* can your envisioned plugin automatically recursively release all other
dependencies moving upward in the reactor dependency tree?
Generalising this out a bit, if it's not a multi-module build we're talking
about, and it's not in SVN (repo per project/module in Git for example),
how will the
live?
by looking into scm tag, and using still one more convention (to be
decided)
where to look locally before attempting independent remote clone.
Original Message
Subject: Re: Multi-project releases
From: Fred Cooke fred.co...@gmail.com fred.co...@gmail.com
To: Maven
] Apache 3.1.0-alpha-1
From: Fred Cooke fred.co...@gmail.com fred.co...@gmail.com
To: Maven Developers List dev@maven.apache.org dev@maven.apache.org
Date: Thu 04 Apr 2013 10:31:57 AM CDT
Can you not programatically access the dependencies by index? Sure it would
be fragile to dep order changes
AFAIK, there is no feature to evaluate before inheritance: this would
require
a new notation than ${xxx}, which could be interpreted before inheritance
If I recall correctly, and I still need to apologise to you for my last
mistake, there is something like @{} in use in one of the (core?)
/plugins/maven-invoker-plugin/examples/filtering.html
Le vendredi 24 mai 2013 13:01:08 Fred Cooke a écrit :
AFAIK, there is no feature to evaluate before inheritance: this would
require
a new notation than ${xxx}, which could be interpreted before inheritance
If I recall correctly
@value@ when cloning projects to the
target, so the ${value} are only resolved during execution.
Robert
Op Fri, 24 May 2013 18:59:20 +0200 schreef Fred Cooke
fred.co...@gmail.com:
Definitely not that, I've not used it, however something else does have a
@{} syntax, something common. I'm
+1(million) non-binding, but if you want, I'll have your children if you
make this extremely positive change 3
On Wed, May 29, 2013 at 12:31 PM, Jörg Schaible joerg.schai...@scalaris.com
wrote:
-1 (nb)
Stephen Connolly wrote:
We have been using a policy of only making releases without
I'm totally fine with the 1.0-RC0 1.0-RC1 1.0-RC2 == 1.0 thing, in Git you
don't even have to copy anything ;-)
If you're going to do trial releases, then RCX is one good way to do it.
I've got to point out, though, that skipped numbers means exactly NOTHING
:-) You *always* skip numbers, by
You're voting on a set of sources, and the state of them, more than the
specific binary built on a specific platform. You're not really voting on
the arbitrary binary that manifests itself as a result of those sources and
build. Although it's possible to build from the same sources and get a
are cheap
Was it what you intended to vote on, and was it how Stephen was thinking to
orient the sentence and the +1/-1 meaning?
2013/5/29 Fred Cooke fred.co...@gmail.com
+1(million) non-binding, but if you want, I'll have your children if you
make this extremely positive change 3
-1 for actual releases: it would create more mess imo for end users if
there's many bizarre jumps in numbering
The thing with this argument is that it's very, very weak. If a missed
version confuses a user, they're basically brain-dead. Assuming your users
are brain dead is _always_
not?)
After step 3, we currently delete the tag, go back to step 1. And
release
again reusing the same version number from the first time.
-Chris
On Thu, May 30, 2013 at 6:11 AM, Fred Cooke fred.co...@gmail.com
javascript:;
wrote
, if the vote passed, then it's 'valid' release.
That fact that we have more than one release of anything means that we
sometimes get it wrong.
-Chris
On Thu, May 30, 2013 at 8:38 PM, Fred Cooke fred.co...@gmail.com wrote:
Are you saying that tags for 2.1 and 2.2.0 of Maven itself should
suggesting to
retroactively go back and remove tags that are not the latest release.
Which I believe is against the apache rules.
-Chris
Sent from my iPhone
On 30/05/2013, at 10:06 PM, Fred Cooke fred.co...@gmail.com wrote:
Point missed. You said:
It's a huge change; as if you do
As pointed out by Benson, the whole skipping thing *should* be a non-issue
anyway. If doing a release you should already know that it's good enough.
You should already have tested it thoroughly on your own OSes. You should
have already requested other devs to build from a hash/buildnumber and
Nice solution, +1.
On Fri, May 31, 2013 at 11:41 AM, James Nord (jnord) jn...@cisco.comwrote:
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: 31 May 2013 10:29
To: Maven Developers List
Subject: Re: [VOTE] Should we respin CANCELLED
from my experience, even if this question is not absolutely scm-specific,
git
brings us a new problem we didn't have with svn: once a tag is set on the
canonical repo and replicated on developers' repos, it is not automatically
updated if updated in the canonical
Git brings you no such
Benson, read the rules:
http://httpd.apache.org/dev/voting.html
*-1 *No, I *veto* this action.
+1 + -1 != 0
On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies bimargul...@gmail.comwrote:
On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke fred.co...@gmail.com wrote:
from my experience, even
, 2013 at 3:08 PM, Baptiste MATHUS bmat...@batmat.net
wrote:
That link is for HTTPd.
For Apache general guidelines, read
http://www.apache.org/foundation/voting.html
-1 are only vetos for code modification, not procedural issues .
Cheers
2013/6/2 Fred Cooke fred.co...@gmail.com
handlers provide, of which git is but one.
-Chris
On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke fred.co...@gmail.com wrote:
from my experience, even if this question is not absolutely
scm-specific,
git
brings us a new problem we didn't have with svn: once a tag is set
are still talking about the abstraction
api
that the maven-scm handlers provide, of which git is but one.
-Chris
On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke fred.co...@gmail.com
wrote:
from my experience, even if this question is not absolutely
scm-specific,
git
Absolutely, sebb! This is what I've been saying all along. If I had more
time I'd vote -1 to every attempted release that used or intended to use
respun tags/artifacts without revisions and checksums. So here's one for
this one until rectified properly -1!
On Tue, Jun 25, 2013 at 12:28 PM, sebb
Not really, no. The developer may have re-spun it again and be about to
email again. You have no idea what you're looking at unless you know the
revision. SVN will die off within a decade and this discussion will become
critical. Better to figure out how to support proper techniques now, rather
I very much prefer your method, Uwe! There are lots of ways to do this
right. I hope one of those is chosen.
On Tue, Jun 25, 2013 at 9:15 PM, Uwe Schindler u...@thetaphi.de wrote:
Hi,
I agree with sebb. I am not a Maven committer, but the release revision is
very important in the Lucene
Especially in other environments where it's used properly, by its own
principals! :-p
On Tue, Jun 25, 2013 at 9:43 PM, Hervé BOUTEMY herve.bout...@free.frwrote:
Le mardi 25 juin 2013 21:15:11 Uwe Schindler a écrit :
This is a slightly different
workflow, but is proven to work since years
-released tags. Once he sends the email though the tag
will be
valid.
Sure having the revision number helps but unless the RM
completely
screws
up the tag should be sufficient.
Ralph
On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
Not really, no. The developer may have
:42 PM, Gary Gregory garydgreg...@gmail.comwrote:
On Jun 28, 2013, at 7:05, Fred Cooke fred.co...@gmail.com wrote:
For git the unique hash is sufficient, you don't really need the tag at
all, they simply point to the unique hash (or another tag, in a chain). If
Git was the SCM of choice, I'd use
SNAPSHOT
builds are for...
Fred.
On Fri, Jun 28, 2013 at 2:21 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On Friday, 28 June 2013, Fred Cooke wrote:
For git the unique hash is sufficient, you don't really need the tag at
all, they simply point to the unique hash (or another
For Git the only thing that is needed is the unique 40 character hash such
as this:
FreeAir:youtube-dl fred$ git rev-parse HEAD
48bfb5f2387ab47e1973d9db0782a9af66ffc4e6
It's just sloppy not to do this; if a quality release process is required,
so is the SVN rev number. If good enough is OK, then
OK, so what is the Git command to download a copy of the sources that
are part of the hash?
git checkout hash
Then observe the tree. You can also export an archive, though I don't
recall the exact command off the top of my hand.
Don't I need to know something about the Git repo it comes
Deleting and recreating a Git tag once published is an *extremely* stupid
thing to do, at least an order of magnitude more so than the same action in
SVN. I sincerely hope that developers in this community would not engage
in such activities.
Nevertheless, this thread isn't about that, it's
Re second checkouts, you're already hurting some (admittedly minority of)
users (not me) with LARGE source trees by doing this at all. Keep this in
mind and at least make any checking out optional...
Perhaps if the SCM plugins were ignore aware they could read this info
and compare it with some
On Sat, Jul 13, 2013 at 7:01 PM, Robert Scholte rfscho...@apache.orgwrote:
Op Fri, 12 Jul 2013 23:31:47 +0200 schreef Arnaud Héritier
aherit...@gmail.com:
What are the SCM coordinates?
Where is the KEYS file?
sebb is a bot in fact ;-P
:) so I don't need to repeat myself explaining
10/10 to Jason for not reusing the existing tag name! 3
On Mon, Jul 15, 2013 at 8:57 PM, Arnaud Héritier aherit...@gmail.comwrote:
Hi Jason,
It seems we have 2 tags in Git for maven 3.1 : maven-3.1 and maven-3.1.0
I think that the the right one to keep is the second one (893ca28 - 28th
Agreed, but as discussed the nicer appaoach would be to use tags in the
form 3.1.0-0...N and then point the final tag at the hash pointed to by the
successful spin's tag, if you insist on this whole respinning thing.
On Mon, Jul 15, 2013 at 9:36 PM, Jason van Zyl ja...@tesla.io wrote:
Sure,
What was the hash for future reference? This is why sebb is sooo right. If
you have a unique coordinate, you're good for life, no matter what gets
done to the SCM. (more or less)
On Mon, Jul 15, 2013 at 9:53 PM, Arnaud Héritier aherit...@gmail.comwrote:
done
On Mon, Jul 15, 2013 at 9:36 PM,
My 2c:
- J7 on Mac is unstable (trust me...) and non-performant, and thus I
require my users to use Apple's J6 on the Mac.
- On Linux there are lots of Swing bugs in all versions, but a lot less
in J7 than J6, so I recommend J7 for Linux guys.
- I don't use J5 for anything at all
BOUTEMY herve.bout...@free.fr
wrote:
uh, another bot?
Le lundi 15 juillet 2013 22:28:26 Fred Cooke a écrit :
What was the hash for future reference? This is why sebb is sooo
right.
If
you have a unique coordinate, you're good for life, no matter what
gets
done to the SCM
-developer-toolsto
see if we can get something that is a bit more focus on facts.
e.g. we are all OSS developers: thus premium/extended/sustaining
support
contracts are outside our budget. If we cannot test it for free, we
cannot
support it.
On 16 July 2013 09:01, Fred Cooke fred.co
1) No opinion.
2) No opinion.
3) HUGE +1
Thanks for your efforts! :-)
On Tue, Jul 23, 2013 at 1:54 PM, Jason van Zyl ja...@tesla.io wrote:
Hi,
I updated the plugin-testing tools to work with Maven 3.1.0 to help Manfred
get the Android Maven Plugin's test harness working with 3.1.0. A couple
+1, unsure if you could have muddied the essentially simple question
much more, but OK. :-p
On Tue, Jul 23, 2013 at 4:00 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
+1 (binding)
On 23 July 2013 14:59, Stephen Connolly
stephen.alan.conno...@gmail.comwrote:
This vote is to
BIG +1 for 6, and small -1 for 7 for my own selfish reasons. The old
versions will always be available, and are forkable for anyone that needs a
fix, hence small -1 and not crying and moaning.
On Tue, Jul 23, 2013 at 4:51 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 23 July
Just remove the and from the end of it...
On Wed, Jul 24, 2013 at 3:30 PM, Martin Gainty mgai...@hotmail.com wrote:
can anyone reach the URL?
Baptiste is it possible to repost comments for build-helper to pastebin?
http://pastebin.com/
Date: Wed, 24 Jul 2013 15:20:33 +0200
Subject:
I really appreciate your regularly inserted pieces of Irish humour and
often chuckle at them! Keep that up! :-)
What matters most to me is not the Apache legal stuff, nor good
behaviour/political correctness, rather it's technical excellence and
honesty in achieving it, even if at the expense of
So much in-crowd politics and unspoken but apparently well-known material.
Who is the person, who if they were to come across this, would obviously
know they were being talked about anyway?
Where is the, almost certainly short lived, fork of Maven located? A quick
search failed to reveal this.
:
On 25 July 2013 23:15, Fred Cooke fred.co...@gmail.com wrote:
So much in-crowd politics and unspoken but apparently well-known
material.
Who is the person, who if they were to come across this, would obviously
know they were being talked about anyway?
I would rather we not focus
:05:44 Fred Cooke a écrit :
About the fork, though, I'm interested. I'm interested in why it's
maintained and how it differs. I'm interested because I intend to fork it
myself to fix things which would break others which I know won't change
upstream (site and release stuff). Perhaps someone
Of course, if anyone is working down stream of this, they will hate you,
and it should be left as is.
On Sat, Jul 27, 2013 at 1:36 PM, Fred Cooke fred.co...@gmail.com wrote:
Yes, easily, if it's the HEAD just do a --amend on it and update it
yourself, Jason's name will be retained. If it's
.
hint: See the 'Note about fast-forwards' in 'git push --help' for
details.
Did I do something wrong? Or git repo at ASF is configured to avoid such
things?
Regards,
Hervé
Le samedi 27 juillet 2013 13:37:12 Fred Cooke a écrit :
Of course, if anyone is working down stream
again.
hint: See the 'Note about fast-forwards' in 'git push --help' for
details.
Did I do something wrong? Or git repo at ASF is configured to avoid such
things?
Regards,
Hervé
Le samedi 27 juillet 2013 13:37:12 Fred Cooke a écrit :
Of course, if anyone is working down
My most humble apologies to Herve for leading you astray! I was unaware of
the policy on this. I hope that I didn't inadvertently cause any harm.
On Sat, Jul 27, 2013 at 3:38 PM, Fred Cooke fred.co...@gmail.com wrote:
On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier aherit...@gmail.comwrote
the current comment is incomplete.
Anyhow, now I know about this.
Robert
Op Sat, 27 Jul 2013 15:40:05 +0200 schreef Jeff Jensen jeffjensen@**
upstairstechnology.com jeffjen...@upstairstechnology.com:
On Sat, Jul 27, 2013 at 8:38 AM, Fred Cooke fred.co...@gmail.com wrote:
On Sat, Jul 27, 2013
Yes it is, I've done it very often:
http://subversion.apache.org/**faq.html#change-log-msghttp://subversion.apache.org/faq.html#change-log-msg
(although I use the GUI for it)
Robert
Op Sat, 27 Jul 2013 16:07:09 +0200 schreef Fred Cooke
fred.co...@gmail.com:
Good practice is to work
:
so, this time:
svn +1
git -1
:)
more seriously: if we cannot fix comments later, we'll need to be more
careful
when committing
Regards,
Hervé
Le samedi 27 juillet 2013 16:27:50 Fred Cooke a écrit :
How did I know you'd say that? You think I didn't know you could do that?
LOL :-p
This ought to keep you out of trouble if you're a downstream user:
NEVER git pull
NEVER git merge
ALWAYS git fetch remote
ALWAYS git merge --ff-only remote/branch
ALWAYS git rebase remote/branch
[image: http://stuff.fredcooke.com/IDontAlwaysMergeButWhenIDoI.jpg]
rebase -i is your friend if used
Yes, I've been guilty of it from time to time, as most have been,
especially years ago ;-)
Did you find any of the above useful? I hope so :-)
Coincidental-Fred.
On Sun, Jul 28, 2013 at 12:26 AM, Barrie Treloar baerr...@gmail.com wrote:
On 28 July 2013 07:45, Fred Cooke fred.co...@gmail.com
+1 on pushing out regression-free fixes and moving forward.
+1 on frequent and small releases and moving forward.
On Sun, Jul 28, 2013 at 6:36 PM, Jason van Zyl ja...@tesla.io wrote:
On Jul 28, 2013, at 12:25 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
I'd like to work on cd tonight
Tag deleted? :-/
On Mon, Jul 29, 2013 at 3:37 PM, Jason van Zyl ja...@tesla.io wrote:
Tag deleted, repository dropped, and now re-released and restaged.
https://repository.apache.org/content/repositories/maven-034/
On Jul 29, 2013, at 9:22 AM, Dennis Lundberg denn...@apache.org wrote:
Nope, I sent it directly to you to avoid noise on the list, but if you
insist on being a and spamming everyone, so be it.
On Mon, Jul 29, 2013 at 4:06 PM, Baptiste MATHUS m...@batmat.net wrote:
2013/7/29 Fred Cooke fred.co...@gmail.com
On Mon, Jul 29, 2013 at 3:57 PM, Baptiste MATHUS m
Jason, there seems to be no trace of either the new or old tag for 3.1.1 on
either ASF server or github. Did you push it? Did you not push it on
purpose?
What are your plans for tags until the release plugin is updated to allow
creation of suffixed tags during the release to be supplemented by a
not attempted to release 3.1.1 and I have not sent out any release
vote. I do intend to add what Sebb suggested by adding the revision.
On Jul 29, 2013, at 12:02 PM, Fred Cooke fred.co...@gmail.com wrote:
Jason, there seems to be no trace of either the new or old tag for 3.1.1
on
either
Are definitions of cat A and B and others listed anywhere? I searched but
failed.
I assume Cat A = permissive and Cat B = copyleft? or?
On Fri, Aug 2, 2013 at 6:54 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Correct. And it would be subject to the same CTR and potential veto
, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Google: Apache third party licenses
Should work on lucky... Or look at the head revision where I added the
link.
There is a 3rd category: Category X... Eg GPL, which we are not allowed to
use
On Friday, 2 August 2013, Fred Cooke wrote
Please keep such information leakage optional. The editing of, and indeed
adding of, the tag element by the release plugin should already be
optional IMO. Especially if it breaks formatting of the POM, which it does
in some cases, at least. And yeah, I know why, and I know it's not a
trivial fix.
...@apache.org wrote:
On 10 August 2013 23:06, Fred Cooke fred.co...@gmail.com wrote:
Please keep such information leakage optional. The editing of, and indeed
adding of, the tag element by the release plugin should already be
optional IMO.
Why?
With such information I know which tag has been used
Which renders most of the tag stuff useless in GIT.
LieGrue,
strub
- Original Message -
From: Fred Cooke fred.co...@gmail.com
To: Maven Developers List dev@maven.apache.org
Cc:
Sent: Saturday, 10 August 2013, 15:19
Subject: Re: What is the correct Git SCM URL
Where, and also when; don't forget that. This is old news, but a pat on
sebb's back for beating the stick regardless of how much it seems to
irritate everyone to hear that noise.
On Tue, Aug 13, 2013 at 7:58 PM, Dennis Lundberg denn...@apache.org wrote:
On Tue, Aug 13, 2013 at 12:30 AM, sebb
Just saw your tag, BIG +1 for me, on no basis other than you seem to care
about the quality of your work.
On Wed, Aug 14, 2013 at 6:03 PM, Andreas Gudian andreas.gud...@gmail.comwrote:
Anyone?
If I can't collect the results today, I won't be able to do it for another
week or so.
Am
It's NOT trolling... If you feel trolled, grow some skin.
On Thu, Aug 15, 2013 at 1:24 AM, Olivier Lamy ol...@apache.org wrote:
On 15 August 2013 08:53, sebb seb...@gmail.com wrote:
On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote:
On Wed, Aug 14, 2013 at 10:47 AM, sebb
Dennis, effectively what is required is a statement like this: I believe
that I've released XYZ binaries from ABC sources (tarball + N patches, SCM,
whatever) with enough info to exactly identify what XYZ and ABC are
(checksums, URLs, revisions, etc) without guessing and duplicated
Right so far?
No, you're not. Step three, in SVN, requires reviewing history to confirm
no changes were made to that URL *ever*. In Git, step 3 involves knowing
the hash, as spurious tags have already been known to circulate.
Even if all of the details were in the POM, the question still
.
On Thu, Aug 15, 2013 at 10:33 PM, Dennis Lundberg denn...@apache.orgwrote:
On Thu, Aug 15, 2013 at 10:24 PM, Fred Cooke fred.co...@gmail.com wrote:
Right so far?
No, you're not. Step three, in SVN, requires reviewing history to confirm
no changes were made to that URL *ever*. In Git
it takes to do that.
No, wait. Sebb and Jason already have that nailed the down.
Good men, those two.
Fred.
On Thu, Aug 15, 2013 at 11:21 PM, Dennis Lundberg denn...@apache.orgwrote:
Hi Fred,
On Thu, Aug 15, 2013 at 10:48 PM, Fred Cooke fred.co...@gmail.com wrote:
Actually, I missed
It's funny that you cite no time and use the equivalent of 299.5 6 digit
revision numbers to send us an email on your lack of time. You could have
done 299 releases to Sebb's quite reasonable standards with that much
keyboard activity. Point made? :-p
On Fri, Aug 16, 2013 at 1:14 AM, Olivier Lamy
16, 2013 at 12:11 PM, Barrie Treloar baerr...@gmail.com wrote:
On 16 August 2013 08:54, Fred Cooke fred.co...@gmail.com wrote:
It's funny that you cite no time and use the equivalent of 299.5 6
digit
revision numbers to send us an email on your lack of time. You could have
done 299
Dennis, I've been using (and mostly loving) the release plugin/process for
the better part of a decade and certainly claim to understand it well. I
don't see how my knowledge of that (or Sebb's perceived lack of knowledge
of that) is in any way relevant. The release plugin means it's harder to do
Dennis, of course source bundles will contain URLs and hashes and revisions
and so forth, and the chance of those being mismatched is approximately
zero. That's not the point.
The point (for me, at least) is what did you INTEND to release, and does
THAT match what is actually found in the bundle
.
On Sat, Aug 17, 2013 at 12:00 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
That sounds like you are looking for the SHA1 sum of the source bundle to
be included in the vote email. Which would seem perfectly reasonable to me.
On 16 August 2013 12:31, Fred Cooke fred.co
I understood that the purpose of the SCM *URL* was to be able to *use*
it with a tool (where browser != tool), as such, there is only one
correct URL, the rest are paths for browsing on a file system or
web-front end. I did this knowing it would fail to illustrate the
point:
24, 2013 at 5:08 PM, Baptiste Mathus m...@batmat.net wrote:
See http://maven.apache.org/pom.html#SCM Hervé is talking about
xpath:/SCM/url which is indeed a scm web ui and said (developer)Connection
would be discussed in another thread.
Cheers
Le 24 août 2013 16:57, Fred Cooke fred.co
You're in Git now. You don't *have* to push your tag and release commits up
to the public world until AFTER you've checked they're OK. Or by failed
release do you mean voted down? They could live on branches until set in
stone, then merge --ff-only into master at that point, if so.
On Sat, Sep
sept. 2013 à 19:30, Fred Cooke fred.co...@gmail.com a écrit :
You're in Git now. You don't *have* to push your tag and release
commits up
to the public world until AFTER you've checked they're OK. Or by
failed
release do you mean voted down? They could live on branches until set
hardware without forcing people to use another repo hosting.
LieGrue,
strub
- Original Message -
From: Fred Cooke fred.co...@gmail.com
To: Maven Developers List dev@maven.apache.org
Cc:
Sent: Saturday, 14 September 2013, 20:48
Subject: Re: Leaving Maven Core POMs
on dedicated branches.
-
Arnaud
Le 14 sept. 2013 à 19:30, Fred Cooke fred.co...@gmail.com a écrit :
You're in Git now. You don't *have* to push your tag and release
commits up
to the public world until AFTER you've checked they're OK. Or by
failed
release do you mean
maintained manually.
LieGrue,
strub
- Original Message -
From: Fred Cooke fred.co...@gmail.com
To: Maven Developers List dev@maven.apache.org
Cc:
Sent: Saturday, 14 September 2013, 21:51
Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
I agree on skipping
. Otherwise the release
notes
would be broken - or would need to get maintained manually.
LieGrue,
strub
- Original Message -
From: Fred Cooke fred.co...@gmail.com
To: Maven Developers List dev@maven.apache.org
Cc:
Sent: Saturday, 14 September 2013, 21:51
of the project unless there is a compelling reason to do
otherwise.
On Sep 14, 2013, at 7:48 PM, Fred Cooke fred.co...@gmail.com wrote:
Jason, PLEASE understand that you do NOT have a single user. Not even
one.
Nada. Zilch. You have developers. Developers, by definition, are not
*completely
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 Cooke
fred.co...@gmail.com:
Last time someone asked this I went straight to central and found
Sep 2013 02:05:55 +0200 schreef Fred Cooke
fred.co...@gmail.com:
Last time someone asked this I went straight to central and found two
examples. There are plenty out there. I'm not doing it again, you're more
than capable. Also note, it's not much different to go from 3.1.2 to
3.1.4
Sent from my iPhone
On 15 Sep 2013, at 12:30, Fred Cooke fred.co...@gmail.com wrote:
Exactly! :-)
On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
But you asked the wrong jump then.
It would be 3.0.5 to 4.0.4... There's no way
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
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 fred.co...@gmail.com wrote:
Version ranges are extremely useful for this case: lib 0.2.4 0.3.0 non
inclusive where lib has a guaranteed stable API
+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
Congratulations, Jason! :-)
On Fri, Oct 4, 2013 at 10:56 PM, Jason van Zyl ja...@tesla.io 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
+1 too, 1.5 is dead for me.
On Mon, Oct 7, 2013 at 8:12 PM, Dennis Lundberg dennisl.apa...@gmail.comwrote:
+1 to 1.6 for 3.2
On Sat, Oct 5, 2013 at 5:03 AM, Jason van Zyl ja...@tesla.io wrote:
Given the vote we had about releases after September does anyone mind if
I update the
+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 ol...@apache.org wrote:
Hi,
We fixed 9 issues. The new feature is the jgit provider (based on jgit).
Details:
I like you more and more! :-)
On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl ja...@tesla.io 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
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
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
1 - 100 of 175 matches
Mail list logo
