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 de
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
(meani
il, and so on)
> -1 = please do not reuse number, numbers 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
>
> > +1(million) non-binding, but if you want, I
>
> -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_ dangero
h every release, or stay
> mostly
> > > the
> > > > same. Eg Kristian has been release manager for Surefire by
> consistently
> > > > stepping up and cutting releases, but if any other committer wanted
> to
> > >
> No, by their own rules, 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 wrote:
>
> >
that you were 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 wrote:
>
> > Point missed. You said:
&
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
verif
Nice solution, +1.
On Fri, May 31, 2013 at 11:41 AM, James Nord (jnord) wrote:
> > -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 releases w
> 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 wrote:
> On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke wrote:
> >> from my experience, even if this question i
t's the reference I was looking for.
>
>
> On Sun, Jun 2, 2013 at 3:08 PM, Baptiste MATHUS
> wrote:
> > That link is for HTTPd.
> > For Apache general guidelines, read
> > http://www.apache.org/foundation/voting.html
> > -1 are only vetos for "code m
at the maven-scm handlers provide, of which git is but one.
>
> -Chris
>
>
> On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke wrote:
>
> > > from my experience, even if this question is not absolutely
> scm-specific,
> > > git
> > > brings us a new problem we
e one who mentioned git in that post.
>
> Please remember what stephen pointed out (which I thought was rather nicely
> worded): [paraphrased]
>
> The real release is the source bundle, and the tags are
> merely a convienance to a developer.
>
> -Chris
&g
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 w
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
tha
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 wrote:
> Hi,
>
> I agree with sebb. I am not a Maven committer, but the release revision is
> very important in the Lucene Project (where
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 wrote:
> 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 now.
> great workfl
t really too much to ask?
> >> >>>
> >> >>> [1] A revision on its one is insufficient as the ASF uses a shared
> SVN
> >> >>> repo; the location within the tree is needed to be able to select
> the
> >> >>> revelant portion of the tree.
e. That's a bit of a
clue.
Fred.
On Fri, Jun 28, 2013 at 1:42 PM, Gary Gregory wrote:
> On Jun 28, 2013, at 7:05, 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 tag, in a
e that SCM hash/rev by, that's what 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 ne
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, the
>
> OK, so what is the Git command to download a copy of the sources that
>
are part of the hash?
>
git checkout
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 f
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 about
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 wrote:
> 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 why
10/10 to Jason for not reusing the existing tag name! <3
On Mon, Jul 15, 2013 at 8:57 PM, Arnaud Héritier wrote:
> 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
> June) ?
> I
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 wrote:
> Sure, drop the older on
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 wrote:
> done
>
>
> On Mon, Jul 15, 2013 at 9:36 PM, Jason van Zyl w
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 an
;
> > On Mon, Jul 15, 2013 at 10:40 PM, Hervé BOUTEMY > >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.
&
hat current versions of Maven support Java 5 and 6, the real
> >>>>>> question is how important is it for older applications that cannot
> >>> support
> >>>>>> Java 7 to be able to use future versions of Maven?
> >>>>
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 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
> things:
+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
wrote:
> +1 (binding)
>
>
> On 23 July 2013 14:59, Stephen Connolly
> wrote:
>
>> This vote is to cover the minimum required version of Java for Maven Cor
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 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: Re: P
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 h
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.
S
en.alan.conno...@gmail.com> wrote:
> On 25 July 2013 23:15, Fred Cooke 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
ay.
Fred.
On Sat, Jul 27, 2013 at 9:56 AM, Hervé BOUTEMY wrote:
> Le vendredi 26 juillet 2013 01: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 t
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 not HEAD then do rebase -i
then mark the one of interest for
comment edit and proceed.
On Sat, Jul 27, 2013 at 1:28 PM, Hervé BOUTEMY wrote:
> IIUC, this is a fix to https://jira.
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 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&#x
jected because the tip of your current branch is
> behind
> > hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
> > hint: before pushing again.
> > hint: See the 'Note about fast-forwards' in 'git push --help' for
> det
; hint: Updates were rejected because the tip of your current branch is
> behind
> >> hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
> >> hint: before pushing again.
> >> hint: See the 'Note about fast-forwards' in 'git
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 wrote:
> On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier wrote:
>
>> At Apache i
In this case I would have liked to see a fix on the
> comment if possible, because the current comment is incomplete.
>
> Anyhow, now I know about this.
>
> Robert
>
>
> Op Sat, 27 Jul 2013 15:40:05 +0200 schreef Jeff Jensen upstairstechnology.com >:
>
>
> On Sat
even possible"
>
> Yes it is, I've done it very often:
> http://subversion.apache.org/**faq.html#change-log-msg<http://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
te:
> 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
This ought to keep you out of trouble if you're a downstream user:
NEVER git pull
NEVER git merge
ALWAYS git fetch
ALWAYS git merge --ff-only /
ALWAYS git rebase /
[image: http://stuff.fredcooke.com/IDontAlwaysMergeButWhenIDoI.jpg]
rebase -i is your friend if used appropriately.
As mentioned,
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 wrote:
> On 28 July 2013 07:45, Fred Cooke wrote:
> > [1] http://pr
+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 wrote:
> On Jul 28, 2013, at 12:25 PM, Hervé BOUTEMY wrote:
>
> > I'd like to work on cd tonight
> >
> > so if you wait for tomorrow..
Tag deleted? :-/
On Mon, Jul 29, 2013 at 3:37 PM, Jason van Zyl 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 wrote:
>
> > Yes, the loss of Maven 2.2.
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 wrote:
> 2013/7/29 Fred Cooke
>
> > On Mon, Jul 29, 2013 at 3:57 PM, Baptiste MATHUS wrote:
> >
&
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 f
>
> I have 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 wrote:
>
> > Jason, there seems to be no trace of either the new or old tag for 3.1.
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 vet
at 7:39 PM, 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
> u
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.
wrote:
> On 10 August 2013 23:06, 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.
>
> Why?
> With such information I know
eople use
> > false and
> > true
> >
> > Which renders most of the stuff useless in GIT.
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > - Original Message -
> >> From: Fred Cooke
> >> To: M
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 wrote:
> On Tue, Aug 13, 2013 at 12:30 AM, sebb wrote:
> > On 12 Au
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 wrote:
> Anyone?
>
> If I can't collect the results today, I won't be able to do it for another
> week or so.
>
> Am Sonntag, 11. August 2013 s
It's NOT trolling... If you feel trolled, grow some skin.
On Thu, Aug 15, 2013 at 1:24 AM, Olivier Lamy wrote:
> On 15 August 2013 08:53, sebb wrote:
> > On 14 August 2013 21:21, Dennis Lundberg wrote:
> >> On Wed, Aug 14, 2013 at 10:47 AM, sebb wrote:
> >>
> >>> On 13 August 2013 18:58, Denn
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
research/looki
>
> 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 re
ence. :-/
Fred.
On Thu, Aug 15, 2013 at 10:33 PM, Dennis Lundberg wrote:
> On Thu, Aug 15, 2013 at 10:24 PM, Fred Cooke wrote:
>
> > >
> > > Right so far?
> > >
> >
> > No, you're not. Step three, in SVN, requires reviewing history to confirm
>
n about what 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 wrote:
> Hi Fred,
>
> On Thu, Aug 15, 2013 at 10:48 PM, Fred Cooke wrote:
>
> > Actually, I misse
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 Lam
sibly,
Fred
On Fri, Aug 16, 2013 at 12:11 PM, Barrie Treloar wrote:
> On 16 August 2013 08:54, Fred Cooke 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 c
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
s
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 (
e huge
overkill.
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.
>
>
>
>
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:
fred@cheetah:~/workspa
, Aug 24, 2013 at 5:08 PM, Baptiste Mathus 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, "Fr
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 14
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
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
>
- 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
> > >>
> >
would be broken - or would need to get maintained manually.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > - Original Message -
> >> From: Fred Cooke
> >> To: Maven Developers List
> >> Cc:
> >> Sent: Saturda
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
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
* 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
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
> 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:
> &
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 wrote:
>
> > Version ranges are extremely useful for this case: lib 0.2.4 >> 0.3.0 non
> > inclusive where lib has a g
+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
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 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?
>
+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.
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
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
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
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
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é
> > >
>
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
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
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
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
+
+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
1 - 100 of 184 matches
Mail list logo
