IMO, we now have tools (Hudson) to guarantee a good quality for
integration build and putting us on the way to rolling release and
continuous delivery.
For SWTBot, I have to admit that making a release is just a "marketing"
effort in order to make some blog posts and tweets, because of its good
test suite, any snapshot which has tests working is better than the last
release. It's actually a continuous delivery on the snapshots, and I've
already recommended people to use snapshots many times because it's
better than previous release and I don't have time to spend on the
release right now. Basically, almost every snapshot could become a
release when you can trust your test suite.
Allowing project to have rolling-release/continuous-delivery was
something Andrew already mentioned on the CBI mailing-list, and I think
it's a good way to go for some projects. It's all the more true when
projects don't have a schedule or a roadmap because they're
community-driven, and change when community wants it to change.
When it comes to "release train", we should understand that as a quality
label which is given once a year: being part of release train means that
the version of your project you submit does conform to release train
requirements/level of quality. It should not (and AFAI Understand, it
does not) enforce a schedule for any project: a project that wants 3
releases in one year can do it, and project that did not have a release
in previous year can resubmit an older version to release train.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
