The Apache Commons Team is pleased to announce the release of Apache
Commons CLI 1.3.
The Apache Commons CLI library provides an API for parsing command line
options passed to programs. It's also able to print help messages detailing
the options available for a command line tool.
1.3 is binary co
+1
Bruno
From: sebb
To: dev@commons.apache.org
Sent: Sunday, May 10, 2015 12:33 AM
Subject: [PROPOSAL][Git] Tidy up SVN repos for components using Git
Following on from the discussion, here is what I propose.
***The intention is to ensure that the SVN repo is not used by
accident
2015-05-08 18:27 GMT+02:00 sebb :
> The git owner is shown as
>
> owner ARRAY(0x2b87708)
>
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=summary
>
> This looks odd.
>
I agree. I'll create a JIRA for this.
Thank you!
Benedikt
>
>
Hello,
2015-05-03 17:18 GMT+02:00 Benedikt Ritter :
> Hi,
>
> We have fixed quite a few bugs and added some significant enhancements
> since CLI 1.2 was released and the Groovy Project is asking for a new
> release, so I would like to release CLI 1.3. The most notable change is the
> introduction
On Sat, May 9, 2015 at 2:35 PM, sebb wrote:
> Poms cannot be changed *after* release.
No, but you can release a new one.
> There may even be some CVS references in early POMs; that does not
> mean the ASF has not migrated away from CVS.
Quite so. And I can't remember a single case where that p
On 9 May 2015 at 13:17, Jochen Wiedmann wrote:
> On Sat, May 9, 2015 at 12:14 PM, Benedikt Ritter wrote:
>> hm, the problem may be, that the scm section of the poms in the pre-git
>> releases point to the svn location.
>
>
> If so, then the project hasn't really migrated to git, has it?
Poms can
Le 03/05/2015 17:18, Benedikt Ritter a écrit :
> Hi,
>
> We have fixed quite a few bugs and added some significant enhancements
> since CLI 1.2 was released and the Groovy Project is asking for a new
> release, so I would like to release CLI 1.3. The most notable change is the
> introduction of a
Following on from the discussion, here is what I propose.
***The intention is to ensure that the SVN repo is not used by
accident, but still allow users to find the Git repo if they only have
the SVN URL.***
[Note: as part of the move to Git, the SVN repo is made read-only by Infra]
Once the Git
On Sat, May 9, 2015 at 12:14 PM, Benedikt Ritter wrote:
> hm, the problem may be, that the scm section of the poms in the pre-git
> releases point to the svn location.
If so, then the project hasn't really migrated to git, has it?
Jochen
--
Any world that can produce the Taj Mahal, William S
If I recall correctly, when the Jenkins project migrated all its repositories
from SVN to Git, the repositories were a) made read-only, b) emptied and its
content replaced by a README file with the link to the new repo and, after some
time, c) deleted.
Bruno
From: Jan Matèrne (jhm)
To
> > > > Do the Git repos include the Subversion commit history?
> > >
> > > Yes, it includes the full history, including tags.
> > >
> >
> > Seems reasonable to drop then.
> >
>
> hm, the problem may be, that the scm section of the poms in the pre-git
> releases point to the svn location.
We coul
2015-05-08 21:55 GMT+02:00 Gary Gregory :
> On Fri, May 8, 2015 at 9:02 AM, Luc Maisonobe wrote:
>
> > Le 08/05/2015 17:55, Adrian Crum a écrit :
> > > Do the Git repos include the Subversion commit history?
> >
> > Yes, it includes the full history, including tags.
> >
>
> Seems reasonable to dr
Fixed now.
Thank you!
2015-05-08 22:05 GMT+02:00 Phil Steitz :
> On 5/8/15 12:51 PM, Timo wrote:
> > Hello everyone,
> >
> > I just noticed that the release notes for 3.4 [1] are a 404. Can
> > someone with access take a look, please?
>
> Thanks for pointing this out. As a workaround until we g
13 matches
Mail list logo
