On 11/13/2015 08:12 AM, Gilles wrote:
On Mon, 9 Nov 2015 10:34:43 -0600, Ole Ersoy wrote:
If I'm interested in some functionality that is 'beta' then I first
have to realize that it's 'beta'...Maybe just tag the branch beta.
After that there's probably (Judging from the number of people
communicating here) 1/2 people interested. Isn't it easier for them
to just just check out the beta branch and manage the process
internally using their own internal 'beta' naming convention until
they are happy with the quality?
[IIUC]
With this approach, I think that we won't get feedback from would-be
testers who don't want to have to "manually" download and compile.
You could be right. Personally, I'm fine doing:
`git clone ...`
`mvn install`
`get to work..`
I'm assuming the critical feedback is being targeted at the more complex
components that are hard to find in the wild, so testers have a natural impetus
to jump through a few hoops.
We need to _release_ the beta versions.
Also, for CM developers, what you describe does not seem to add
anything: they already can create branches and experiment locally.
True. I'm assuming that someone needing a feature will first google, find out
that what they are looking for is available - and is potentially better in the
beta version - so they will be ok with building and experimenting with the
branch locally.
From here it looks like the core problem is that there are two many
modules intermingled in CM causing friction / weighing down the
release process for each of the individual modules (Which I'm
currently imagining).
Could be... :-}
The complexity of multiple interdependent features being refactored
simultaneously might also turn some off. If multiple beta branches are created
isolating each change it could make it easier to request and process feedback.
Cheers,
- Ole
Regards,
Gilles
Cheers,
- Ole
On 11/06/2015 06:51 PM, Gary Gregory wrote:
On Fri, Nov 6, 2015 at 4:02 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
On 11/6/15 4:46 PM, Gary Gregory wrote:
On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz <phil.ste...@gmail.com>
wrote:
On 11/6/15 2:51 PM, Gary Gregory wrote:
On Fri, 6 Nov 2015 09:17:18 -0700, Phil Steitz wrote:
Here is an idea that might break our deadlock re backward
compatibility, versioning and RERO:
Agree that odd numbered versions have stable APIs - basically
adhere
to Commons rules - no breaks within 3.0, 3.1, ..., 3.x... or 5.0,
5.1... but even-numbered lines can include breaks -
...
This sounds awfully complicated for my puny human brain.
How, exactly? Seems pretty simple to me. The even-numbered release
lines may have compat breaks; but the odd-numbered do not.
It's bad enough that I have to remember how each FOSS project treats
versions numbers, but having an exception within a Commons component is
even worse. This is a non-starter for me.
Do you have any better suggestions? The problem we are trying to
solve is we can't RERO while sticking to the normal compat rules
without turning major versions all the time, which forces users to
repackage all the time and us to support more versions concurrently
than we have bandwidth to do.
I do not see how a different version scheme will determine how many
branches the community supports.
If we just keep one 4.x branch that keeps cutting (possibly
incompatible) releases, that is just one line, one branch. If we
have to cut 4.1, 4.2, 4.3 as 4, 5, 6 instead and we don't allow any
compat breaks, we end up having to maintain and release 4.0.1,
5.0.1, 6.0.1 instead of just 4.3.1, for example, or we just strand
the 4, 5 users in terms of bug fixes as we move on to 6.
Breaking BC without a package and coord change is a no-go.
We have done this before and we will probably do it again - and more
if we have to don't separate out an unstable line.
You have to
think about this jar as a dependency that can be deeply nested in a
software stack. Commons components are such creatures. I unfortunately
run
into this more than I'd like: Big FOSS project A depends on B which
depends
on C. Then I want to integrate with Project X which depends on Y which
depends on different versions of B and C. Welcome to jar hell if B and C
are not compatible. If B and C follow the rule of break-BC -> new
package/coords, then all is well.
The mitigation here is that we would not expect the even-numbered
releases to be deployed widely.
Respectfully Phil, my point is that while this might be true, it is in
practice irrelevant. We cannot control the spread of our jars and their
usage, hence the importance of BC.
Gary
Phil
Gary
Phil
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
