Considering the low frequency of releases and the small number of new
features, the version management structure of James seems to be an
overkill.
(Or maybe I just don't understand the system.)
Although I don't think this is new for anybody here is the simplest
procedure:
The trunk receives all changes. It must always be in a useable state.
Compatibility doesn't matter at all, you don't release more then once a
year anyway now. Moreover James is a mature product, nobody is forced to
upgrade. I am using the same custom version for about 3 years if not more.
If there are enough features or a few months elapsed, release a beta
version from the trunk. The beta can be put into a new branch if a
serious bug is found. Leave it in beta for a few months, and if nobody
reports serious bugs declare it stable. The version number should
reflect the actual backward compatibility of the beta, there is no need
to plan it in advance.
Noel J. Bergman írta:
After discussion of various technical and non-technical things at ApacheCon
by Robert, Bernd, Norman and myself, here's a road forward.
When I get a moment (right now, I am in the planning meeting for ApacheCon
US New Orleans), I am going to branch from v2.3.1. I am going to re-review
the diff between v2.3.0 and v2.3.1, and welcome others to do the same. It
is not that I don't want some of the code from trunk, but this is just part
of the process.
The production branch is not necessarily intended to be config.xml and
DB-format compatible with v2.x. The purpose is to start from a production
stable codebase, and maintain a production stable code base, while
incrementally incorporating stable parts pulled from and shared with trunk,
or developed in a temporary sandbox.
As another part of the process, Robert is going to work on refactoring and
splitting from trunk. To illustrate the overall process, one of the things
that Robert is going to do is pull out all of the portable Matchers and
Mailets into a separate releasable. Once that's clean, we compare them
against the same set in the production branch, and after approving, we
delete them from the production branch, and reference the new package.
Trunk will also share that same releasable, so in that manner, we will
effectively "merge" production and trunk incrementally over time.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
