[Vtigercrm-developers] Versioning, stable and devel branches and business models

[Jeff Kowalczyk]

We have various threads active right now about support for the
vtigercrm-4.x series, opening up the trunk to additional community input,
etc.

FWIW, I'm going to start a trac wiki page (once authorized in trac) to
codify the versioning scheme that was discussed over the past year. We had
a defect in the name under which vtigercrm-5.0.0beta1 was released,
something I had hoped to get brushed up before the product left alpha.
We'll get there...

I do want to make a point that won't belong on the wiki page or other
official docs:

  The ability of the vtigercrm project to release packaging-, migration-
  and lifecycle-supported products at predictable intervals will directly
  impact the viability of business models depending on vtigercrm support
  contracts and paid feature development.

  vtigercrm should follow the example of other projects and release on a
  strict 3 or 6 months cycle, with each release supported for a defined
  number of months, such as 18.

  Features should undergo both an inclusion and deprecation process to
  regulate the speed and timing of change.

  The vtiger core team and other developers building business around
  vtigercrm would find it easier to sell support contracts and services
  for this market, and customers would find it easier to justify buying
  those support services.

These are only observations based on the abrupt transition from
vtigercrm-4.2.3 to vtigercrm-5.0.0. I think the work that is ongoing with
vtigercrm-4.2.4 and vtigercrm-4.2.5 should be built into the business plan
of the vtiger team. It's in everyone's interest to see that a stable
branch has a long lifecycle.

I'd like to learn from this transition to see if we can engineer a better
process for a possible vtigercrm-5.5.0 for December 2006.