Dear Anders,
> -----Original Message-----
> From: Anders Peterson [mailto:anders_peterso..ptimatika.se]
> If there are 10 bug fix releases before a new feature release we'll
just
> have to call it 1.1.0 - we should try to avoid this. I really think we
> should limit the number of releases. Users who absolutely want the
> latest features or bug fixes should build from source.
I couldn't disagree with you more. For organizations that deploy the
package to multiple computers, especially busy organizations, going
through a build, and then deploying rather than grabbing an update from
eclipse central is a much more difficult task. I think regular patching
is quite reasonable, especially since I can't see there being a limit
preventing a 1.1.10, 1.1.11, etc.
I know many developers are quite cavalier about build vs. package and
see the latter as laziness on the part of some user, but actually going
through a package and deploy to an auto-update system is a level of
quality control that behooves any project. In my tracking of the
OpenBSD ports process, on of the watershed moments in the quality of the
ports system was when all installations, even directly when building
from source through the build system, went through the packaging process
and installed from a binary package. It required that all the ports had
the minimum sanity check of satisfying the packaging system's
constraints. WoLips would benefit from this as well, I believe.
> The main reason to have branches would be to allow making a bug fix
> release although work on the next feature release has already begun.
>
> As I understand it branches can be cretaed as (when) needed. If we
> create a version for a release, we can then branch on that version if
> and when it becomes necessary.
Agreed. Upon producing a release candidate you tag a version, and when
you decide that a given candidate is final, you branch from that tag,
and all patches are then controlled on that branch. Any new
development, or patches not intended to be rolled into a patched version
of the previous release go on the HEAD.
Regards,
Christian.
This archive was generated by hypermail 2.0.0 : Fri Apr 04 2003 - 09:57:30 EST