Re: [Dltk-dev] code freeze

[Andrey Platov <andrey@xxxxxxxxx>]

Hi Jae,

Welcome back, hope you enjoyed your vacations and nice to see you in the saddle.

As for 1.0, there is no consensus yet and I'm thinking now that 1.0 in September proposal which came from my side was bad idea. Consider what we have now:

* There are several commercial products based on DLTK, some product release often (say on quarterly basis).
* Other products have longer release cycle, which is not synchronized with Eclipse Simultaneous Release. For example PDT 2.0 will be released this December.

DLTK is not mature, so products which releasing often require some changes in DLTK, so they can't stay with last release (say 0.95). Idea of 1.0 in September was to "make" it mature, so vendors will be able to stay with it for a longer time (year) - but now it looks we are not reached such level of maturity yet. At least PHP folks would like to introduce some new concepts before their December release.

In this situation we can do following:

A) Release often (say each 3 months): 0.96, 0.97... and I hope we'll be mature after 0.99 :) But this would result in significant overhead:
  1. We'll need to provide formal plan to Eclipse Foundation
  2. We'll need to prepare, set up, and pass Release Review for each version (even 0.x) as required by Eclipse Process.
  3. This also may not help. For example PDT want to go on the market Dec 1st, but DLTK 0.9x scheduled for Dec 23.

So here is plan B
  1. We do not reinvent a wheel and DLTK release will be synchronized with Eclipse Simultaneous Releases (BTW current is Galileo, http://wiki.eclipse.org/Galileo).
  2. Galileo Release Dates are available, DLTK Core will be on Galileo+1 release date until we depend on Eclipse Platform only.
  3. What we need is to carefully plan Milestones to support vendors who releases often or out of sync with Simultaneous Release. General rules following:

* Each milestone is 6 weeks. 4 weeks of development + 2 weeks of stabilization (bugfixing). During stabilization weeks we do not implementing new features, doing significant refactoring, changing API, etc. 
* Committers working on new features targeted to next milestones are welcome to create feature branches to survive stabilization weeks - I believe it will be merged back easily when new milestone started, just because stabilization weeks do not assume significant changes in HEAD.
* Vendors sync up with some milestone according to their release plans. And welcome to help making this milestone stable enough for their release :)
* Since most vendors bundle DLTK as a part of the product, and do not expect their product to be updated from eclipse.org update site - all the above looks OK.
* If some milestone went to product, and critical problems were found, we may branch from it at release Mna, MnB, etc to support that particular vendor.

Back to your question Jae, either plan A and plan B assumes that we will have stable version on Sep 24, and Sep 10 is a start for "stabilization"/release process. So you're welcome to help with any aspects or if you're going to work on things, which requires heavy changes, please do this in branch.

Thank you, and
Kind Regards,
Andrey

----- Original Message -----
From: "Jae Gangemi" <jgangemi@xxxxxxxxx>
To: "DLTK Developer Discussions" <dltk-dev@xxxxxxxxxxx>
Sent: Friday, September 5, 2008 9:58:06 PM GMT +06:00 Almaty, Novosibirsk
Subject: [Dltk-dev] code freeze

hello all -

  i'm back from all vacations, etc and ready to get back into the saddle again - what's going on w/ the code freeze for the 1.0 release? i want to figure out what my next steps are going to be if it is right around the corner.

  thanks!

--
-jae

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev