[Erp5-dev] ERP5 Release System - proposal

[Łukasz Nowak]

Hello,

We present our idea how to organise release management for ERP5. We
would like to know your opinion about this idea. Any constructive
comments as well as criticism are welcome. We are making this proposal
in good faith - to provide the best possible solution in implementing
and development of ERP5 system, to give as much as possible possibility
to arise community of skilled developers around such great project as
ERP5 is itself.

Mikołaj Antoszkiewicz
Tomasz Bochenek
Bartek Górny
Jacek Mędrzycki
Łukasz Nowak

= Proposal =

== Rationale ==

While working on ERP5 system we've been hit with many problems when
upgrading the system. Additionally it is very hard to choose '''a
good''' revision. Having in mind fact, that nowadays ERP5 is developed
and used by developers with different knowledge and skills associated
with ERP5 system it is good to provide them quite stable version of
ERP5.

That's why we are proposing a draft of stabilisation releases of ERP5.

== Releases Advantages ==
 * Releases will accelerate, facilitate and lower cost of learning ERP5
system and maintenance of running ERP5 sites.
 * Releases will not disturb ability to commit new
fixes/features/functionality to HEAD - upports will force developer
using release to synchronise fixes into HEAD and short release time
will force them to use almost HEAD version.
 * Releases will create contributing community of lightly related users
and developers of ERP5 system.
 * Only current release is supported, with RELEASE-1 to RELEASE upgrade
path. Every question from person using former releases shall be
answered with '''Upgrade to current release.'''
   * this will drastically lower cost of releases' maintenance - cost
of release + cost of '''one''' upgrade path This also will force
developers using release to be in sync with HEAD version of code.
 * Release Manager do not have to be highly skilled ERP5 developer,
which will lower cost of generating new release.
 * Releases aren't treated as fully tested, stable version - they are
just ''enough'' tested snapshots - good enough to be used by less
experienced users and developers and current enough for bleeding edge
developers.
 * Experimental developers will not feel any disadvantages when
releases arrive - they still will be using HEAD version, and
synchronised upporting system will give them all fixes generated in
releases.
 * Releases may be triggered on upstream request, which will force
horde of upstream related and non-related developers to help with
release.
 * Release will be created in less than 8 working days.
 * Core developer would be able to focus on developing bleeding edge
code - synchronisation and backward compatibility might be suspended to
next release cycle.
 * Having so often releases is guaranteeing users and developers short
times of getting freshest code.
 * Having releases won't stop users and developers from fetching HEAD
version of code to be able to participate in very current stage of ERP5
code development.
 * Proposed release scenario kept in mind minimum release's maintenance
cost and is trying to have minimal impact on current development way of
ERP5 (this release scenario as much as possible tries to accelerate
development of ERP5). Also it kept in mind keeping minimal cost at side
of upstream.
 * Releases are very positive on marketing - many users and future
clients will be happy if they see "ERP5 Release 200804".
 * As implementing ERP is quite complex problem and ERP5 installation
is not simple (it couldn't be - this is _complex_ and generic system)
releases will provide kind of good feeling to newcomers - releases will
provide them good starting point.

=== Summary ===
Releases will lower running cost of sites, will not stop developers
from fixing HEAD and will make initial installation of ERP5 sites
easier.

== Releases ==
First release will be created after 1 full month after this draft
publication.

Releases time windows '''might''' be consulted with upstream and/or
large contributors/users of ERP5 - if needed.

Release Manager (or Release Manager Team) ('''RM''') is responsible for
release, everyone needs to support him in his work.

Releases shall be made 4 times per year (every quarter). Upgrade from
one release to the next one '''has to''' be unproblematic - every
additional step, which might create problems, have to be described in
'''Upgrade Notes'''.

Specific sites are allowed to have problems with upgrade - it might be
something with API changes etc, but release have to guarantee that it
is OK. API changes shall be described in '''API Changes'''.

== How to create Release ==

 1. RM is choosing revision with little errors and fails in unit tests
 2. RM is removing backports created on older releases
 3. RM is checking validity and the need for upports for RELEASE
 4. RM is tagging SVN repository on chosen revision, naming it
RELEASE-RC
 5. RM is announcing RELEASE-RC and welcomes experienced community
members to participate in RELEASE scenario
 6. RM is upgrading system from previous RELEASE to RELEASE-RC
 7. Other developers do test upgrades from previous RELEASE to
RELEASE-RC:
   1. When needed they are sending backports/upports to RELEASE-RC
   2. If something important will happen while doing RELEASE-RC it is
added as backport
 8. RM writes and publicise ''What's new'', ''Upgrade Notes'' and ''API
Changes'' for RELEASE-1 to RELEASE-RC
 9. RM is changing tag name from RELEASE-RC to RELEASE and announces
new release

Then is "feature freeze" - nothing more is added - every backport or
upport is only for critical bugfixes.

== Upport/Backport ==

Because creating a RELEASE has side effect of being a little behind
after HEAD, it is necessary to create a backport system (on HEAD there
is a critical bugfix) or upport (something is corrected on RELEASE,
that should be committed).

Every upport shall be proposed to be committed into CORE - if it is
accepted, it would become backport on RELEASE.

Release maintainers '''WILL NOT''' accept any upports, which weren't
send for acceptance to HEAD. No special cases will be claimed.

== Products / Business Templates ==

Business Templates shall have such skin priority:
 1. erp5_trade_upport
 2. erp5_trade_backport
 3. erp5_trade

Products are monkey-patched by creating directories/files
upports/backports, which have monkey-patches with fixes to upport or
backports took from HEAD.

Release maintainers will be obliged to minimise upport/backport size to
minimum - only critical bugfixes or features which were introduced
while release was creating, and are treated as important or essential.

Site maintenance will thus be limited to regularly updating
backports/upports of products and BT's, and every quarter or so
updating everything to the new RELEASE - with upgrade notes etc.

Developers are guaranteed that updates in same release are flawless.

If there would be need to introduce greater changes, new release shall
come.

== Unit tests ==

RELEASE and its iterations are unit tested. It is assumed that upgrade
to next iteration of same RELEASE is non-problematic - almost always it
will be small steps, only critical bugfixes after -RC.

RELEASE-RC is unit tested.

Additional unit test scenario:
 1. save site with previous RELEASE
 2. unit test
 3. '''upgrade''' site to RELEASE (this same site)
 4. unit test
 5. comparison of effects

== Release technical notes ==

Release will be named by time, when release creation happened, eg:
 * 200711 for release in November 2007

Release names might have special codenames, which will follow official
release name, eg:
 * 200804-SPRINGY
Release codenames have to be unique.

Release iteration won't have any additional numbers. Users and
developers have to upgrade to newest current release iteration.

It would be preferred to have special BT downloadable repository for BT
for current (and only current) release.

No upgrade path will be provided to upgrade for more then one release.

As release will be based on tags it is possible to provide full (and
almost never ending) history of release tags in SVN repository. That
way users of former releases would be able (on their own risk) to
upgrade one by one. (Tagging === copying in sense of SVN, which is
"cheap" operation.)

Release might provide possibility to create packages in RPM, DEB or any
suitable form for quick ERP5 installation on target systems.


-- 
Łukasz Nowak R&D Ventis http://www.ventis.com.pl/
tel: +48 32 768 16 85 fax: +48 32 392 10 61
``Use the Source, Luke...''