On 9 October 2013 05:14, Siegfried Goeschl wrote:
> Hi Gary,
>
> A new major release requires a new package name, site, build and so on -
> think of commons-lang v1,2,3
Huh?
A major release does not imply an API break, though the reverse is true.
> Cheers,
>
> Siegfried Goeschl
>
>> Am 08.10.2
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 :
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
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
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
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
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
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
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
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
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
> 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
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
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
+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
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
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
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
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
> 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
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 :)
---
http://www.youtube.com/watch?v=MqitYkILvnQ&feature=player_detailpage#t=63
Gary, really no offense - but I just could not resist :)
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
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
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
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
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
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
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
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
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
31 matches
Mail list logo
