Right - that sounds good to me. And when its a hairy change to back
port, or the change is just really invasive, or breaks back compat in
way you have to jump over hoops to put into stable - then you just put
it in unstable. But generally that is not most changes.
On 04/22/2010 10:08 AM, Earwin Burrfoot wrote:
Okay, let's live with parallel development, but make sure we 'always'
port things from stable to trunk, and 'always' remove possible
back-compat layers when doing such a port?
On Thu, Apr 22, 2010 at 18:04, Mark Miller<markrmil...@gmail.com> wrote:
I'd vote -1 on Shai's variation and +1 on Mike's proposal.
I don't think features should be backported to stable on request. If we go
this route, I think it should be a matter of course unless the feature is
hairy enough to warrant unstable.
Saying we should do all dev on unstable, and only back port on request (who
will police that? everyone will accept all requests?) and that we should
just release trunk more often to accommodate, is like saying, lets just
throw back compat out the window, every release will be free to break back
compat, we will just release more often...
Working on two branches won't be 100% joy, but loosening the existing much
larger annoyance of back compat is not going to be free IMO. To me, Shai's
proposal is essentially - lets keep everything the same, but release more
often (we have decided to that 100 times) and lose back compat requirements.
Then if a dev takes pity on a user, perhaps one of the unstable releases
will get a backport of a feature.
If we take that route, I am vehemently against changing our policy.
On 4/22/10 9:52 AM, Shai Erera wrote:
I was advocating that we always develop on trunk w/ no back-compat support,
API-wise ... you could have developed flex w/ no bw support.
Currently what you're proposing would cause most features to be developed on
stable w/ bw support and trunk w/o. I propose to leave 'stable', develop on
trunk w/ no bw support (except for index format) and back port features "on
demand" to stable w/ bw support.
So instead of forcing all development to go through stable + trunk, I
propose to go through trunk, and back port to stable only if requested. In
the end we'll be in the same position (trunk having all features) except for
stable which will include just those features of interest to other people.
Shai
On Thu, Apr 22, 2010 at 4:12 PM, Michael McCandless
<luc...@mikemccandless.com> wrote:
On Wed, Apr 21, 2010 at 1:56 PM, Shai Erera<ser...@gmail.com> wrote:
The only downside is that we will need to do everything twice: once on
stable and once on trunk. I still think that most of the issues and
development don't affect bw at all and thus we'll always say "this
needs to go to stable and trunk" which will just be an annoyance and
complicate the life of the developers even more because not only will
we need to keep bw compat, we'll need to write the code for trunk as
well.
Well, most things. Some features (eg flex would've been such a
feature) will only happen in trunk.
But, yes, this is a downside -- stable changes will have to be merged
up to trunk.
What if we always develop on trunk, release it more often, and if
requested or a committer needs it, we backport a certain feature to
stable?
This is what we do today, and I think what's broken about it is we are
unable to make a big change that has major breaks from the start.
Every big change is required to land on trunk with back compat intact.
This is terribly costly for changes like the new analyzer API (Token
-> AttrSource migration), and flex.
So with the new model, a big change like flex could land on trunk with
no back compat, and age for a long time, along with other such
changes, before being included in a major release.
I'm not sure we'll release trunk (major releases) more often. I think
it could go both ways...
For small changes, I think whether a given dev works on trunk and
merges back to stable, or stable and merges forwards to trunk, is an
individual choice...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
