On Thu, 10 Oct 2013 11:58:58 -0400, James Carman wrote:
On Thu, Oct 10, 2013 at 10:50 AM, Gilles
wrote:
-1
Some people have indicated that this move might not address the
problem
it is supposed to. No conclusive answer has been provided.
What problem is that exactly? Perhaps that's not w
And how did we establish that git will not address those concerns?
On Thursday, October 10, 2013, Gilles wrote:
> On Thu, 10 Oct 2013 11:58:58 -0400, James Carman wrote:
>
>> On Thu, Oct 10, 2013 at 10:50 AM, Gilles
>> wrote:
>>
>>> -1
>>>
>>> Some people have indicated that this move might not
On 10/10/2013 22:41, James Carman wrote:
> And how did we establish that git will not address those concerns?
It has not been established that the choice of git vs. svn is the
biggest blocker to attracting attention and contributors.
I would suggest that a lack of releases is a much greater barri
On Thu, Oct 10, 2013 at 5:48 PM, Mark Thomas wrote:
>
> I would suggest that a lack of releases is a much greater barrier. Folks
> who contribute patches do so because they want to see them in a release.
> If there are no releases (and looking back for the past 6 months there
> have been very few
On 10/10/2013 23:05, James Carman wrote:
> On Thu, Oct 10, 2013 at 5:48 PM, Mark Thomas wrote:
>>
>> I would suggest that a lack of releases is a much greater barrier. Folks
>> who contribute patches do so because they want to see them in a release.
>> If there are no releases (and looking back fo
On Thu, Oct 10, 2013 at 6:13 PM, Mark Thomas wrote:
>
> I disagree. We don't have releases because of an overly complex release
> process. Figuring out how to do a Pool 2 release is on my TODO list.
> Having seen the pain others new to the Commons release process have gone
> though, I'm not lookin
On 10/10/2013 09:39 PM, Rahul Akolkar wrote:
On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma wrote:
Case in point: SCXML
If we are allowed to start working on this component shortly, we intend to,
and HAVE to switch to a 1.0 version first, as there already is a 0.9 version
release out, while we
Commons SCXML has only one reverse dependency in Maven Central,
flexistate, so I wouldn't bother with the binary compatibility and just
keep the package as is.
http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9
Emmanuel Bourg
--
On Oct 10, 2013, at 18:13, Mark Thomas wrote:
> On 10/10/2013 23:05, James Carman wrote:
>> On Thu, Oct 10, 2013 at 5:48 PM, Mark Thomas wrote:
>>>
>>> I would suggest that a lack of releases is a much greater barrier. Folks
>>> who contribute patches do so because they want to see them in a rel
On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
Commons SCXML has only one reverse dependency in Maven Central,
flexistate, so I wouldn't bother with the binary compatibility and just
keep the package as is.
Hmm. That might be the only reverse dependency of artifacts also deployed to
Maven Centr
We're all still talking about the release process, but in all honesty I've
not done it for several years at Commons. I think it would be immensely
helpful for those of us who have been at least part way through the process
fairly recently (Emmanuel, Gary, others?) to present your recollections of
Even I like git and use it daily, I will vote +0,5.
Why other apache projects need to have their own commons-csv
repackaged release? why tomcat need to use a svn:external on dbcp
instead of a released version? why servicemix need to repackage all
commons jar to have proper osgi bundles?
I simply
If you are breaking backward compatibility then you need to do the renames
(package, and artifactId).
I don't know if we ever landed on a "rule" about the new JDK level
scenario, though.
On Thursday, October 10, 2013, Ate Douma wrote:
> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
>
>> Commons
On 10/11/2013 01:41 AM, James Carman wrote:
If you are breaking backward compatibility then you need to do the renames
(package, and artifactId).
That was my impression already.
And I have no real issue with doing so.
But again, when has this been decided and has it ever been formalized (writt
Now, this case is a bit weird, since we have released code in a < 1.0
version number. So, the artifact/package will have to be scxml1,
which looks funky IMHO. I guess that follows the pattern, though.
On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma wrote:
> On 10/11/2013 01:41 AM, James Carman wrote
> On Oct 10, 2013, at 4:41 PM, Olivier Lamy wrote:
>
> Even I like git and use it daily, I will vote +0,5.
>
> Why other apache projects need to have their own commons-csv
> repackaged release? why tomcat need to use a svn:external on dbcp
> instead of a released version? why servicemix need t
Matt and I will probably have proxy2 ready very soon, too
On Thu, Oct 10, 2013 at 8:10 PM, Phil Steitz wrote:
>
>
>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy wrote:
>>
>> Even I like git and use it daily, I will vote +0,5.
>>
>> Why other apache projects need to have their own commons-csv
>> r
I would bump to version 2.0 because I dont think its clear that going from
0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we
haven't quite completed everything we want to for 1.0"
Niall
On Fri, Oct 11, 2013 at 12:52 AM, James Carman
wrote:
> Now, this case is a bit weird,
I would also treat 0.9 as a "real release" and act accordingly wrt API
changes; the current release is far too old to do otherwise IMHO.
Matt
On Oct 10, 2013 7:41 PM, "Niall Pemberton"
wrote:
> I would bump to version 2.0 because I dont think its clear that going from
> 0.9 to 1.0 is a major ver
It wouldn't look so funky that way. I'm cool with that.
On Thursday, October 10, 2013, Niall Pemberton wrote:
> I would bump to version 2.0 because I dont think its clear that going from
> 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we
> haven't quite completed everythi
The dots aren't decimal separators and version numbers are not true
numbers. 0.9 goes to 0.10 goes to 0.11, etc. If they were true decimal
numbers, you couldn't have more than one dot.
0.9 to 1.0 is a major version jump. However, 0.X usually indicates
pre-release quality (i.e., not ready for produ
On 2013-10-11, Matt Benson wrote:
> We're all still talking about the release process, but in all honesty I've
> not done it for several years at Commons. I think it would be immensely
> helpful for those of us who have been at least part way through the process
> fairly recently (Emmanuel, Gary,
Can a release guy detail what is painful and why we cant release with a
script? Git or svn are scriptable to be auto so the scm is clearly not the
release issue (maybe not fashion but not blocking)
Le 11 oct. 2013 01:24, "Gary Gregory" a écrit :
> On Oct 10, 2013, at 18:13, Mark Thomas wrote:
>
I don't understand why "SCM isn't the biggest problem" causes people to veto
this change.
Send from my mobile device
> Am 11.10.2013 um 06:55 schrieb Romain Manni-Bucau :
>
> Can a release guy detail what is painful and why we cant release with a
> script? Git or svn are scriptable to be auto s
I dont think it vetoes it, it is just not linked
Le 11 oct. 2013 07:47, "Benedikt Ritter" a écrit :
> I don't understand why "SCM isn't the biggest problem" causes people to
> veto this change.
>
> Send from my mobile device
>
> > Am 11.10.2013 um 06:55 schrieb Romain Manni-Bucau >:
> >
> > Can
Benedikt Ritter wrote:
> I don't understand why "SCM isn't the biggest problem" causes people to
> veto this change.
It's not a veto, it's a normal majority decision.
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.ap
101 - 126 of 126 matches
Mail list logo
