Re: [DISCUSS] Proactive Feature Development...

Send from my mobile device > Am 08.10.2013 um 19:04 schrieb Phil Steitz : > >> On 10/8/13 9:48 AM, Benedikt Ritter wrote: >> 2013/10/8 Stefan Bodewig >> On 2013-10-08, James Carman wrote: How about this for an idea? What if instead of waiting until *after* a new JDK come

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

On 2013-10-08, Benedikt Ritter wrote: > you are involved in other projects (like log4j2) how do they do it? Is > it easier to release log4j2 than it is to release for example [lang]? Over the past year I've cut releases at the ASF for Commons Compress, Ant and log4net and outside of the ASF of a

Re: [DISCUSS] API compatibility policy

Hi Gary, A new major release requires a new package name, site, build and so on - think of commons-lang v1,2,3 Cheers, Siegfried Goeschl > Am 08.10.2013 um 22:54 schrieb Gary Gregory : > > On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl > wrote: >> That's a reasonable style of versioning :

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

I wrote the Log4j2 wiki page just so I could remember and repeat the few manual steps I have to do for each release. The difficulty is getting the bugs out of the first release. Log4j 2 still has some difficulties though around its build process primarily because none of us are OSGi experts and

Re: [SCXML] knock knock?

On Tue, Oct 8, 2013 at 9:39 AM, Woonsan Ko wrote: > Yeah, that's great! > State machine is a generic and simplistic concept which can be applied > anywhere. > In our case (Hippo), we want to leverage SCXML library as a core Document > Processing Engine. By exposing state machines in XML with abi

Re: [SCXML] knock knock?

On Tue, Oct 8, 2013 at 9:25 AM, Ate Douma wrote: > On 10/08/2013 02:18 PM, Rahul Akolkar wrote: >> >> Who's there :-) >> >> Agree with all your Commons SCXML related comments below.I've been >> >> out of time for this for a while; you're welcome to have at it. Being >> ASF committers helps as disc

Re: [JCI] Problem with release profile

I made some progress but I still have an issue with 'mvn site', see http://apaste.info/pOvS Again, any idea is welcome. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail

Re: [INFRA][VFS][DISCUSS] Git pull notification mails to dev@

+1!!! On Tue, Oct 8, 2013 at 6:07 PM, Gary Gregory wrote: > Why not simply switch to Git? > > Gary > > On Tue, Oct 8, 2013 at 5:57 PM, Bernd Eckenfels > wrote: >> Hello, >> >> while we are at the topic of helping future commiters, including Git and >> workflow I would like to ask/remind about t

Re: [INFRA][VFS][DISCUSS] Git pull notification mails to dev@

Why not simply switch to Git? Gary On Tue, Oct 8, 2013 at 5:57 PM, Bernd Eckenfels wrote: > Hello, > > while we are at the topic of helping future commiters, including Git and > workflow I would like to ask/remind about this JIRA: > > https://issues.apache.org/jira/browse/INFRA-6764 > > It is ab

[INFRA][VFS][DISCUSS] Git pull notification mails to dev@

Hello, while we are at the topic of helping future commiters, including Git and workflow I would like to ask/remind about this JIRA: https://issues.apache.org/jira/browse/INFRA-6764 It is about enabling pull notification mails for [VFS] and havent seen much activity yet. (Maybe I should no

Re: [DISCUSS] API compatibility policy

A good resource if you didn't know it existed: http://commons.apache.org/releases/versioning.html On Tue, Oct 8, 2013 at 3:54 PM, Gary Gregory wrote: > On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl > wrote: > > That's a reasonable style of versioning :) > > > > I had many issues with binar

Re: [DISCUSS] API compatibility policy

On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl wrote: > That's a reasonable style of versioning :) > > I had many issues with binary compatibilty with a commons-email release due > to changing the return value from void to a this reference plus some moving > of constants. You basically end up

Re: [DISCUSS] API compatibility policy

That's a reasonable style of versioning :) I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases Cheers

Re: [JCI] Problem with release profile (was: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?)

Yes. On 8 October 2013 20:40, Benedikt Ritter wrote: > Do you have included the latest commons parent pom? > > > 2013/10/8 sebb > >> On 8 October 2013 19:06, Benedikt Ritter wrote: >> > Maybe it's a problem with the maven-bundle-plugin. It should generate >> the Manifest for you. I'm on my mobi

Re: [DISCUSS] API compatibility policy

On 8 October 2013 21:11, Gary Gregory wrote: > On Tue, Oct 8, 2013 at 2:11 PM, sebb wrote: >> On 8 October 2013 17:36, Gary Gregory wrote: >>> On Oct 8, 2013, at 10:09, James Carman wrote: >>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg wrote: > > That's not the issue. We want

Re: [DISCUSS] API compatibility policy

On Tue, Oct 8, 2013 at 2:11 PM, sebb wrote: > On 8 October 2013 17:36, Gary Gregory wrote: >> On Oct 8, 2013, at 10:09, James Carman wrote: >> >>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg wrote: That's not the issue. We want to avoid unresolvable incompatibilities in trans

Re: svn commit: r1530336 - /commons/proper/jci/trunk/fam/src/test/java/org/apache/commons/jci/monitor/FilesystemAlterationMonitorTestCase.java

On 8 October 2013 17:11, wrote: > Author: ebourg > Date: Tue Oct 8 16:11:41 2013 > New Revision: 1530336 > > URL: http://svn.apache.org/r1530336 > Log: > Disabled an assertion in testDeleteFileDetection failing on Windows (this is > not a regression, the same assertion fails with JCI 1.0) > > M

Re: [JCI] Problem with release profile

Le 08/10/2013 21:25, sebb a écrit : > However, there are other commons components with multiple modules; it > should be possible to get some clues from them. Thank you for the suggestion, I found the solution in vfs. Emmanuel Bourg --

Re: [JCI] Problem with release profile (was: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?)

Do you have included the latest commons parent pom? 2013/10/8 sebb > On 8 October 2013 19:06, Benedikt Ritter wrote: > > Maybe it's a problem with the maven-bundle-plugin. It should generate > the Manifest for you. I'm on my mobile right now and will not have the time > to have a look until to

Re: [JCI] Problem with release profile (was: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?)

On 8 October 2013 19:06, Benedikt Ritter wrote: > Maybe it's a problem with the maven-bundle-plugin. It should generate the > Manifest for you. I'm on my mobile right now and will not have the time to > have a look until tomorrow. It's not only the osgi Manifest. I tried copying an existing Ma

Re: [JCI] Problem with release profile

Le 08/10/2013 20:06, Benedikt Ritter a écrit : > Maybe it's a problem with the maven-bundle-plugin. It should generate the > Manifest for you. I'm on my mobile right now and will not have the time to > have a look until tomorrow. Could this be caused by the fact that jci is a multi module projec

Re: [jci] New release?

Send from my mobile device > Am 08.10.2013 um 20:34 schrieb sebb : > >> On 8 October 2013 18:19, Emmanuel Bourg wrote: >> Le 08/10/2013 18:29, Benedikt Ritter a écrit : >> >>> there was this issue with the failing test related to the eclipse compiler. >>> Can you comment on this? Is it fix? I

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

On 8 October 2013 19:44, Christian Grobmeier wrote: > On 8 Oct 2013, at 20:07, Benedikt Ritter wrote: > >> Hey Gary, >> >> you are involved in other projects (like log4j2) how do they do it? Is it >> easier to release log4j2 than it is to release for example [lang]? > > > Check this guide: > http:

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

On 8 Oct 2013, at 20:07, Benedikt Ritter wrote: Hey Gary, you are involved in other projects (like log4j2) how do they do it? Is it easier to release log4j2 than it is to release for example [lang]? Check this guide: http://wiki.apache.org/logging/Log4j2ReleaseGuide In fact we have an ASF m

Re: [jci] New release?

On 8 October 2013 18:19, Emmanuel Bourg wrote: > Le 08/10/2013 18:29, Benedikt Ritter a écrit : > >> there was this issue with the failing test related to the eclipse compiler. >> Can you comment on this? Is it fix? If it's broken, should we document it? > > As I understand it already exists in JC

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

I think I understand what Gary means. I once wrote down the process to release Apache Portals Application for other PMC members here: - http://wiki.apache.org/portals/Applications/Release_Process I guess the process is almost the same in other projects (log4j2 or possibly lang). There are many t

Re: [DISCUSS] API compatibility policy

On 8 October 2013 17:36, Gary Gregory wrote: > On Oct 8, 2013, at 10:09, James Carman wrote: > >> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg wrote: >>> >>> That's not the issue. We want to avoid unresolvable incompatibilities in >>> transitive dependencies. Our components are used by many p

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Luckily, Ralph handles release manager duties, for which I am grateful. So I cannot speak to the ease or difficulty of the process there. Gary On Oct 8, 2013, at 14:08, Benedikt Ritter wrote: > Hey Gary, > > you are involved in other projects (like log4j2) how do they do it? Is it > easier to

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Hey Gary, you are involved in other projects (like log4j2) how do they do it? Is it easier to release log4j2 than it is to release for example [lang]? Benedikt Send from my mobile device > Am 08.10.2013 um 19:52 schrieb Gary Gregory : > > IMO the problems are dealing with Nexus, a web site, a

[JCI] Problem with release profile (was: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?)

Maybe it's a problem with the maven-bundle-plugin. It should generate the Manifest for you. I'm on my mobile right now and will not have the time to have a look until tomorrow. Benedikt Send from my mobile device > Am 08.10.2013 um 19:25 schrieb Emmanuel Bourg : > > Le 08/10/2013 18:46, Bened

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

IMO the problems are dealing with Nexus, a web site, and a 'dist' directory; that THREE things to get just right, none are 100% automated. With Nexus you have to do some manual steps. If you look at all the instructions for any commons component, it is long, a combo of manual and Maven+Nexus magic

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Le 08/10/2013 18:46, Benedikt Ritter a écrit : > What are the problems and how can we make releasing easier? I have a real example with JCI. I get an error when running the release profile with "mvn package -DskipTests -Prelease" : [INFO] [ERR

Re: [jci] New release?

Le 08/10/2013 18:29, Benedikt Ritter a écrit : > there was this issue with the failing test related to the eclipse compiler. > Can you comment on this? Is it fix? If it's broken, should we document it? As I understand it already exists in JCI 1.0, so nothing new on this side. Emmanuel Bourg --

Re: [DISCUSS] Proactive Feature Development...

On 10/8/13 9:48 AM, Benedikt Ritter wrote: > 2013/10/8 Stefan Bodewig > >> On 2013-10-08, James Carman wrote: >> >>> How about this for an idea? What if instead of waiting until *after* >>> a new JDK comes out (and in some cases MANY years later), we start >>> with pre-release versions in a branc

Re: [SCXML] knock knock?

Yeah, that's great! State machine is a generic and simplistic concept which can be applied anywhere. In our case (Hippo), we want to leverage SCXML library as a core Document Processing Engine. By exposing state machines in XML with ability to add custom actions and other declarative configuratio

Re: [DISCUSS] Proactive Feature Development...

2013/10/8 Stefan Bodewig > On 2013-10-08, James Carman wrote: > > > How about this for an idea? What if instead of waiting until *after* > > a new JDK comes out (and in some cases MANY years later), we start > > with pre-release versions in a branch or something to start using the > > new langua

[DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Hi, one of the points that seem to always come up once in a while is the process of releasing components. I've never done it myself so I'm asking people who have done it: What are the problems and how can we make releasing easier? Is the complexity of the parent pom a problem? (Do we really need

Re: [DISCUSS] API compatibility policy

The only relaxing I could see is for code in internal packages. Gary On Oct 8, 2013, at 12:28, James Carman wrote: > Okay, so what I'm hearing is that we want to relax our "no API breaks > within a major release" policy. Also, it sounds like we need to come > up with the naming convention wher

Re: [DISCUSS] API compatibility policy

On Oct 8, 2013, at 10:09, James Carman wrote: > On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg wrote: >> >> That's not the issue. We want to avoid unresolvable incompatibilities in >> transitive dependencies. Our components are used by many projects, an >> incompatibility could render impossibl

Re: [jci] New release?

Hi Emmanuel, there was this issue with the failing test related to the eclipse compiler. Can you comment on this? Is it fix? If it's broken, should we document it? Thanks! Benedikt 2013/10/8 Emmanuel Bourg > Le 08/10/2013 12:02, Torsten Curdt a écrit : > > Not sure what has changed since the

Re: [DISCUSS] API compatibility policy

Okay, so what I'm hearing is that we want to relax our "no API breaks within a major release" policy. Also, it sounds like we need to come up with the naming convention where we can rope off parts of our API as implementation details and they're not to be relied upon by outside parties (they may d

Re: [DISCUSS] API compatibility policy

> On Oct 8, 2013, at 7:08 AM, James Carman wrote: > >> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg wrote: >> >> That's not the issue. We want to avoid unresolvable incompatibilities in >> transitive dependencies. Our components are used by many projects, an >> incompatibility could render

Re: [DISCUSS] Proactive Feature Development...

WRT [functor], this process has been ongoing; ex: the recent inversion of its API names such that unary functor types get the "unadorned" names (i.e. Function/Predicate/Procedure to be more in-line with Java 8). AIUI lambdas buy you the ability to tersely implement single-method interfaces, so [f

Re: [SCXML] knock knock?

Thanks for warm welcoming! We'll clearly communicate and document every feature/issue/task. So, please chime in any time if needed. Cheers, Woonsan > > From: Ate Douma >To: dev@commons.apache.org >Sent: Tuesday, October 8, 2013 9:25 AM >Subject: Re: [SCXML]

Re: [DISCUSS] Proactive Feature Development...

Le 08/10/2013 16:04, James Carman a écrit : > Are there any other features of JDK8 that we think could be > used by our projects? You may want to rethink [functor] in a Java 8 context. Emmanuel Bourg - To unsubscribe, e-mail:

Re: [jci] New release?

Le 08/10/2013 12:02, Torsten Curdt a écrit : > Not sure what has changed since the last release but a release is certainly > overdue. Here is the list of user visible changes I compiled from JIRA and the SVN history. Let me know if I forgot something important. Fixed bugs: o Fixed a NPE in Files

Re: [DISCUSS] API compatibility policy

On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg wrote: > > That's not the issue. We want to avoid unresolvable incompatibilities in > transitive dependencies. Our components are used by many projects, an > incompatibility could render impossible the use of two components > together, and you are st

Re: [DISCUSS] API compatibility policy

Le 08/10/2013 15:46, James Carman a écrit : > Another concept I'd like to bring up is the fascination we seem to > have with protecting the users from being blithering idiots. That's not the issue. We want to avoid unresolvable incompatibilities in transitive dependencies. Our components are used

Re: [DISCUSS] Proactive Feature Development...

On Tue, Oct 8, 2013 at 10:00 AM, Stefan Bodewig wrote: > > In compress I have created a branch that used snapshot releases of XZ > for Java or developed Zip64 support in a branch (which required Java5 > when compress was at 1.4 compatibiity). Torsten used to do some API > refactoring in a branch

Re: [DISCUSS] Proactive Feature Development...

On 2013-10-08, James Carman wrote: > I am not saying we rule it out or anything. I'm talking about ideas > that could be fun. I don't remember us ever doing something like > that. Well, my vision is somewhat narrow as I tend to stay in my little corner in compress and only occasionaly lurk anyw

Re: [DISCUSS] API compatibility policy

+1 Stefan On 2013-10-08, James Carman wrote: > Agreed. I think we should come up with a naming convention. The OSGi > community (the maven bundle plugin) has adopted the notion that any > package named "impl" or "internal" will not be exported. Perhaps we > set up that expectation to our user

Re: [DISCUSS] Proactive Feature Development...

I am not saying we rule it out or anything. I'm talking about ideas that could be fun. I don't remember us ever doing something like that. On Tue, Oct 8, 2013 at 9:44 AM, Stefan Bodewig wrote: > On 2013-10-08, James Carman wrote: > >> How about this for an idea? What if instead of waiting unti

Re: [DISCUSS] API compatibility policy

Another concept I'd like to bring up is the fascination we seem to have with protecting the users from being blithering idiots. We cannot protect them from themselves completely. At some point, we have to give them the benefit of the doubt that they're not complete morons. If they do indeed do s

Re: [DISCUSS] Proactive Feature Development...

On 2013-10-08, James Carman wrote: > How about this for an idea? What if instead of waiting until *after* > a new JDK comes out (and in some cases MANY years later), we start > with pre-release versions in a branch or something to start using the > new language features? Maybe I'm just naive, bu

Re: [DISCUSS] API compatibility policy

Agreed. I think we should come up with a naming convention. The OSGi community (the maven bundle plugin) has adopted the notion that any package named "impl" or "internal" will not be exported. Perhaps we set up that expectation to our users, too. If it's in a package named as such, then it can

Re: [DISCUSS] API compatibility policy

Sorry, got away from me before I finished. By "other Sw" I meant "other than when someone wants to slip in a comparability break outside a major release." I agree with Luc that we should allow ourselves to designate parts of the API as "internal" so subject to change between major releases. For

Re: [DISCUSS] API compatibility policy

The goal is to level set, so that we don't run into this stuff. On Tue, Oct 8, 2013 at 9:27 AM, Phil Steitz wrote: > > >> On Oct 8, 2013, at 5:52 AM, James Carman wrote: >> >> However, code modifications can be vetoed and nobody can overrule the veto. >> > Honestly, I have not seen that much, ot

Re: [DISCUSS] API compatibility policy

> On Oct 8, 2013, at 5:52 AM, James Carman wrote: > > However, code modifications can be vetoed and nobody can overrule the veto. > Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versi

Re: [SCXML] knock knock?

On 10/08/2013 02:18 PM, Rahul Akolkar wrote: Who's there :-) Agree with all your Commons SCXML related comments below.I've been out of time for this for a while; you're welcome to have at it. Being ASF committers helps as discussed down-thread. I'll continue to lurk, but likely won't be active i

[DISCUSS] Proactive Feature Development...

How about this for an idea? What if instead of waiting until *after* a new JDK comes out (and in some cases MANY years later), we start with pre-release versions in a branch or something to start using the new language features? This way, we can be ready when the new JDK comes out (or shortly the

Re: [DISCUSS] API compatibility policy

That's kind of a mellow song from DMX. He's not yelling as much as usual. On Tue, Oct 8, 2013 at 8:53 AM, Torsten Curdt wrote: > http://www.youtube.com/watch?v=MqitYkILvnQ&feature=player_detailpage#t=63 > > Gary, really no offense - but I just could not resist :) ---

Re: [DISCUSS] API compatibility policy

http://www.youtube.com/watch?v=MqitYkILvnQ&feature=player_detailpage#t=63 Gary, really no offense - but I just could not resist :)

Re: [DISCUSS] API compatibility policy

However, code modifications can be vetoed and nobody can overrule the veto. On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory wrote: > On Tue, Oct 8, 2013 at 8:38 AM, James Carman > wrote: > >> Yes, we know we're allowed to do that, but folks seem to fight against >> moving forward. >> > > All you ne

Re: [DISCUSS] API compatibility policy

On Tue, Oct 8, 2013 at 8:38 AM, James Carman wrote: > Yes, we know we're allowed to do that, but folks seem to fight against > moving forward. > All you need is a [VOTE] and be done with it. Gary > > On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory > wrote: > > You can break BC all you want when

Re: [DISCUSS] Moving to Git...

To me the important thing is getting to an easy workflow for accepting PRs sent to our github mirrors. I think that can be done with git-svn, but this begs the question: if someone has to be running git-svn on every Commons component, why not just use git and skip the middleman? I presume that's

Re: [DISCUSS] Moving to Git...

I think the problem we have right now is perception. We look like dinosaurs. A lot of the current contributions we receive come in as pull requests from Github. If we want to attract new contributions, we need to make it easier for folks to contribute. On Tue, Oct 8, 2013 at 8:24 AM, Romain Man

Re: [DISCUSS] Moving to Git...

Le 08/10/2013 14:02, Christian Grobmeier a écrit : > I know teams which are doing better with SVN. But esp in open > source using SVN looks like the code is maintained by dinosaurs who > don't want to work with "new things". I don't quite agree with the paleontological argument. I don't feel disc

Re: [DISCUSS] API compatibility policy

Yes, we know we're allowed to do that, but folks seem to fight against moving forward. On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory wrote: > You can break BC all you want when you do it in a NEW package. For > example lang3. > > Gary > > On Oct 8, 2013, at 6:41, Torsten Curdt wrote: > >> Cannot

Re: [DISCUSS] API compatibility policy

You can break BC all you want when you do it in a NEW package. For example lang3. Gary On Oct 8, 2013, at 6:41, Torsten Curdt wrote: > Cannot remember which component from the top of my head - but it was > related to package name changes. > > My style of thinking: x.y.z > > x - no compatibility

Re: [DISCUSS] Moving to Git...

i still think the scm is not an issue. the %age of committers is negligible compared to the number of users whatever you use. So you need a nice product first. Tools follow or not...you speak about scm but we can speak abou tbuild tool too, "gradle is far better than maven"...it doesn't help the to

Re: [SCXML] knock knock?

Who's there :-) Agree with all your Commons SCXML related comments below. I've been out of time for this for a while; you're welcome to have at it. Being ASF committers helps as discussed down-thread. I'll continue to lurk, but likely won't be active in the immediate future. Welcome to Commons, -

Re: [DISCUSS] API compatibility policy

On 8 Oct 2013, at 12:48, James Carman wrote: I think the idea is to change the mindset. There seems to be an almost militant desire to maintain compatibility. Yes, we have the version number scheme, but some folks just never want to break compatibility it seems. This stalls innovation. I do

Re: [DISCUSS] Moving to Git...

On 8 Oct 2013, at 11:42, Romain Manni-Bucau wrote: just an habit. svn diff && attach diff to a jira is as easy/hard as git push + PR. Tools like GitHub succeed because not everybody agrees with you. svn/diff is stoneage to some. git/pr is the future for them. Maybe you are right about the h

Re: [DISCUSS] Moving to Git...

+1 to moving to git as well, and the workflow with a pull request + cherry picking or merging by a committer sounds good to me too :) Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com From: luc To: dev@commons.apache.org Sent: Tuesday, October 8,

Re: [jci] New release?

Go for it :) Gary On Oct 8, 2013, at 6:03, Torsten Curdt wrote: > Not sure what has changed since the last release but a release is certainly > overdue. > Release early - release often ;) > Sure! Go ahead! > > > On Tue, Oct 8, 2013 at 11:28 AM, Emmanuel Bourg wrote: > >> Hi all, >> >> I'd like

Re: [DISCUSS] API compatibility policy

I think the idea is to change the mindset. There seems to be an almost militant desire to maintain compatibility. Yes, we have the version number scheme, but some folks just never want to break compatibility it seems. This stalls innovation. I don't want to debate every change, so setting the e

Re: [DISCUSS] API compatibility policy

Cannot remember which component from the top of my head - but it was related to package name changes. My style of thinking: x.y.z x - no compatibility y - source compatibility z - binary compatibility is simple and makes sense. It's OK to put some burden on the users when upgrading - as long as

Re: [DISCUSS] API compatibility policy

On 2013-10-08, Emmanuel Bourg wrote: > Le 07/10/2013 20:14, Benedikt Ritter a écrit : >> - loosen API compatibility policy? > This topic alone deserves its own thread I think. > Ensuring binary/source compatibility is very important. +1 I guess I've done too much ruby with "every bundle updat

Re: [jci] New release?

Not sure what has changed since the last release but a release is certainly overdue. Release early - release often ;) Sure! Go ahead! On Tue, Oct 8, 2013 at 11:28 AM, Emmanuel Bourg wrote: > Hi all, > > I'd like to push out a new release of [jci]. Despite the remaining > issues it's still an im

Re: [DISCUSS] Moving to Git...

just an habit. svn diff && attach diff to a jira is as easy/hard as git push + PR. If you want to push back your changes you'll do whatever the techno is. *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/*

[jci] New release?

Hi all, I'd like to push out a new release of [jci]. Despite the remaining issues it's still an improvement compared to the previous release. Any objection? Emmanuel Bourg signature.asc Description: OpenPGP digital signature

Re: [DISCUSS] Moving to Git...

2013/10/8 Emmanuel Bourg > > I don't think using SVN is a barrier to private modifications like this. > People just fork the mirror on Github, or import the code with git-svn. > > I didn't said it was. Of course you'll do your private change, but you won't share it easily (not as easily as with g

Re: [DISCUSS] Moving to Git...

everybody seems ok for git, maybe time to throw a vote and go to next topics ;) *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github:

Re: [DISCUSS] Moving to Git...

Le 08/10/2013 10:38, Xavier Detant a écrit : > I think, as Luc said, that git is a big plus for that. Let's say you're a > lambda person, you just use commons for work and found a bug you need to > fix for your app. On svn, you'll fix it, use it in your app, but you will > not share it, may be not

Re: [DISCUSS] API compatibility policy

Le 07/10/2013 20:14, Benedikt Ritter a écrit : > - loosen API compatibility policy? This topic alone deserves its own thread I think. Ensuring binary/source compatibility is very important. This is an area where Guava is clearly not a good example, they deprecate and remove stuff frequently. Eve

Re: [DISCUSS] Moving to Git...

I think all your points are important but are not exclusive. I totally agree with Romain, the usage and features are extremely important and we should move on (following Java version, etc…) but the simpler someone can contribute, the faster we'll go. I think, as Luc said, that git is a big plus f

Re: [DISCUSS] Moving to Git...

On 08/10/2013 09:30, Emmanuel Bourg wrote: > Le 08/10/2013 10:02, luc a écrit : > >> This would be *much* easier than attaching patches to JIRA. > > There is an open issue though, when a contributor attaches a patch to > JIRA it leaves a proof that he allowed the ASF to include his code. > Mergin

Re: [DISCUSS] Moving to Git...

Le 08/10/2013 10:02, luc a écrit : > This would be *much* easier than attaching patches to JIRA. There is an open issue though, when a contributor attaches a patch to JIRA it leaves a proof that he allowed the ASF to include his code. Merging directly from Github isn't enough from a legal standpo

Re: [DISCUSS] Moving to Git...

2013/10/8 luc > Hi all, > > Le 2013-10-08 09:10, Romain Manni-Bucau a écrit : > > Never said the opposite but git or svn is not a questioin IMO, both are >> simple and usable today. I'm more attracted by features than the infra >> around a project. >> > > I don't fully agree. The infra is also i

Re: [DISCUSS] Moving to Git...

Hi all, Le 2013-10-08 09:10, Romain Manni-Bucau a écrit : Never said the opposite but git or svn is not a questioin IMO, both are simple and usable today. I'm more attracted by features than the infra around a project. I don't fully agree. The infra is also important (not more or less than ru

Re: [DISCUSS] Moving to Git...

Le 08/10/2013 04:10, James Carman a écrit : > I suppose we'd have a separate repo for each component? What about > proper vs. sandbox? How would we accommodate that paradigm? Has > anyone else already gone through this thought process? Regarding the sandbox vs proper issue, I don't think this

Re: [DISCUSS] Moving to Git...

Send from my mobile device > Am 08.10.2013 um 09:10 schrieb Romain Manni-Bucau : > > Never said the opposite but git or svn is not a questioin IMO, both are > simple and usable today. I'm more attracted by features than the infra > around a project. > > For me commons looks like a big sandbox

Re: [DISCUSS] Moving to Git...

Never said the opposite but git or svn is not a questioin IMO, both are simple and usable today. I'm more attracted by features than the infra around a project. For me commons looks like a big sandbox where rules are more important than features (btw maven is about the same today). From my underst