Hi Mike, > Maybe we can leave unstable on its own branch, and stable remains on > trunk, like it is today?
This somehow reverses the idea behind the folders in SVN. Everybody looking for the latest and coolest things would always look in trunk, never in a branch. Almost all projects have the orginal SVN structure: in A branches folder they do stable development and in trunk the newest things. >From the view of the merging its not different at all. For the SVN below the >folders trunk, branches, tags are just folders no other meaning. These folders >are some standard way to maintain an svn repository and we should do it like >that. Merging works always, regardless of how you structure the dirs. You can >even merge two branches or whatever. So I am -1 on this and I am +1 on simply creating a stable branch like it always was and everybody exspects. The only difference to the past is, that we no also do development on the stable branch. > And, it's not the committer's job to port each little commit to stable > over to the unstable branch. Instead, we periodically re-sync stable > --> unstable, like we did with the long-lived flex branch. > > So, then, little would change on how stable is developed, today. And > stable would still be the primary source line for development. That is also true for a branch. See e.g. PHP development. They have a trunk but at the moment nobody commit there (including me), we are maintaining branches 5.2 and 5.3 at the moment. > Unstable changes would happen on the unstable branch, and only be > merged back to trunk when it's time for the next major release. See above. Uwe > On Thu, Apr 22, 2010 at 11:31 AM, Mark Miller <markrmil...@gmail.com> > wrote: > > 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
