I would like to share with you a proposal we've been internally discussing
for the last days. It's related to 3.0, the split of Core, the modules and
the Mercurial repositories. You'll be the number one audience affected by
these decisions, so your opinion is welcome!
With our current structure we have Core from one side (pi/main) and the
modules in another. This makes sense in 2.50, because Core in this version
is useful by itself, it doesn't need other modules to work. In 3.0 the
story changes: Core is not of use by itself, it needs other modules to
work.
So let me share with you the challenges we have and 2 possible solutions:
one that uses our old approach and another one that proposes a different
solution.
Challenges:
* 3.0 is a distribution of Core + 15 modules.
* Developers: creating and maintaining a development environment.
* Issue tracker, Mantis: reporting bugs.
* SCM, Mercurial: multiple major versions.
* CI, Hudson: how to promote Core + 15 modules as a group.
* Packaging of the release.
Possible solutions:
1) Continue as we are now. Use pi/main for Core and a repository per
module, no matter if it's part of the 3.0 distribution or not.
* Pros:
- It's clean: once repository per entity. One repository for all
the major versions of a module.
* Cons:
- Developers:
. Creating a 3.0 development environment means cloning pi + 15
modules. Maintaining it means updating 16 repositories.
. Reproducing someone's environment is more difficult: you need to
gather info about 16 repositories and update to those exact
revisions.
- Issue tracker:
. It's hard to faithfully report an issue describing the revisions
you are using. Currently "product version" (e.g. pi) and "SCM
revision" affect to Core only. What about the rest of the 15 modules?
e.g. pi in changeset fde3456cb fails with APRM in changeset
67764fecb. Oh, and the application.kernel in 5feca23b, etc. Even if
we can add this as a note, there's no way to filter this when
searching.
- CI:
. This is one of the most difficult parts. Promoting 16 repositories
in a synchronized manner. We'd need 2 repositories per module. We
already have pi and main for Core. We'd need the same for the rest
of the modules.
. Hudson is not designed to use multiple repositories in a nice
manner. It's not possible to view what changes are being tested
using the interface when you're using 16 repositories.
- Packaging:
. You have to externally keep track of what modules versions match
with what core version.
2) As 3.0 is a distribution of modules, take those 15 modules and add them
into the pi/main repositories, inside the modules directory.
* Pros:
- Developers:
. Creating a 3.0 development environment means cloning pi. And
maintaining it means updating 1 repository. Similar to our current
2.50 approach.
. Reproducing someone's environment is simple: there's only 1
revision ID.
- Issue tracker:
. It's easy to faithfully report an issue because there's only 1
revision
- CI:
. The promotion is simplified tremendously. 1 repository, 1
promotion. From pi to main, as usual.
. We can continue making use of the Hudson interface to view changes.
- Packaging:
. No need to externally keep track of what modules match with that
Core version.
* Cons:
- The 3.0 modules would reside in pi/modules. And the 2.50 modules in
erp/mods.
- If you want a 3.0 module which is part of the distribution you need
to clone the entire pi repository.
- If we want to develop a new major version of a module included in the
3.0 distribution, then we'd need to create a separate repository for
that module.
Additional possible questions: in solution 2), what if I want to develop
a new feature in my module? Simple, create a branch of pi and do it as
usual.
Feel free to fire up your questions, comments or additional proposals.
Regards,
Juan Pablo
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Openbravo-development mailing list
Openbravo-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbravo-development
