[Vtigercrm-developers] vTiger mulitple vulnerabilities

[Jeff Kowalczyk]

Allan Bush wrote:
> Mike is correct.
> 
> If a security patch is created it should be released as 4.2.5 (or
> maybe 4.2.4.1 although I think Jeff wants to save that for packaging
> changes) and the planed 4.2.5 release should be pushed to 4.2.6
> although there's enough new features in there to justify calling it
> 4.3.

Right, vtigercrm-4.2.5. A release containing only fixes, whether for
security or logic, would increment the .y in vtigercrm-x.y.z.


The best argument for never releasing anything without a version number is
the chaos vtiger used to have in the forums when people were trading
patches. Most of the time was spent trying to communicate which ones they
had applied, and in which order. It was ridiculous.

If there were things committed in vtigergcrm/branches/4.2 that weren't
ready for a gotta-have-it-now bugfix release, then the procedure would be
to make a release branch from the last appropriate revision, apply the
fix(es), and tag. Then make archives with svn export and announce.

The best hypothetical example, and one that is sure to happen at some
point:

- vtigercrm-4.2.4 is tagged released (r 6930 for example)

- commits are subsequently made in the 4.2 branch, not really ready for
release yet, such as a schema change.

- two security holes are found in vtigercrm-4.2.4

- make a release branch:

  # svn cp -r 6930 (URL)/branches/4.2 (URL)/branches/4.2.5_release 

  (committed revision 9082.)

- commit bug fixes in a working copy of (URL)/branches/4.2.5_release

  # svn switch (URL)/branches/4.2.5_release
  # svn commit 

- tag the emergency bugfix release

  # svn cp (URL)/branches/4.2.5_release (URL)/tags/4.2.5

- merge (URL)/branches/4.2.5_release back to (URL)/branches/4.2

  # svn switch (URL)/branches/4.2
  # svn merge -r 9082:HEAD (URL)/branches/4.2.5_release
  # svn commit