Re: Draft for release policy pending feedback

> Zynot has a 9-12 months release cycle.
>=20
whee!

> =20
>=20
> The arch leads are release managers of each new version of Zynot. They
> maintain different release schedules for each arch. However, their
> effort is coordinated and major releases within each arch should not
> differ from the agreed release date by more than 1-2 months. The
> version numbers follow each other. One arch is not required to wait
> for another arch to be 100% done before releasing.
>=20
sounds reasonable

=20
> The arch leaders gather on a meeting well in advance of a release and
> agree on which features to offer and which package versions to freeze
> for future release. As a result of these meetings, each arch leader
> maintains a roadmap towards release that is public. It should show
> dates for alphas, betas, release candidates planned as well as final
> release date.
roadmaps are good=20

> The version numbering should reflect to the consumer how well this
> release of Zynot will interoperate with earlier releases and how much
> of an advantage it is to upgrade. As we are not a desktop-centric
> distribution our policy on version numbers will differ from that of
> RedHat and Mandrake since these mainly follow the release cycle and
> version numbering of KDE and Gnome.

yup agreed this is a good thing (no bumping to v9 so we look like we
been around as long as RH to the PHB's)


> The arch leaders identify a number of products that are relevant for
> Zynot to offer. This could be a Zynot workstation, a Zynot webserver,
> a Zynot database server, a Zynot development workstation and much
> more. All packages needed to offer each product are provided as
> binaries. Everything that runs on top such as irc clients, media
> players and office suites are offered as ebuilds only.

are we gonna allow whatever ? and is the major definition for this
"product" gonna be a profile ?
> =20
>=20
> Not all products will make sense on all arches. It is up to the arch
> leader to decide what should be offered within his arch. Preferably
> this should be decided based on community feedback and needs. The arch
> lead should note in his public roadmap which products will be offered.
>=20
whee for roadmaps !
> =20
>=20
> The binary packages are frozen. No version bumps will happen unless
> there is a new release of Zynot. The packages provided as ebuilds only
> can freely be updated by the maintainers at their leisure. Security
> updated binary packages are of course an exception from this rule.=20
>=20
um we should release security patches as well..  What use flags are
gonna be defined for the binary packages ? who decides that ? :D

> Zynot must support a migration path going 2 versions back. If Zynot
> has released a v1.0 and a v2.0 then upgrades to v3.0 from BOTH these
> version should be supported and painless. The lifecycle of v1.0 ends
> when v3.0 is released. We will then no longer offer security fixes or
> backports of these for v1.0.=20
2 years for EOL ? hrm .. dunno how that will work out in comercial
environments, but this is a draft :D and maintianing binary patches for
10 archs and 3 releases will be enough work im sure :D

> Thorough and well-tested documentation for =B4upgrading to Zynot vX.X=A1
> should be ready on the release date. The documentation must also, of
> course, go 2 versions back.
>=20
wheee For documentation..
> =20
>=20
> =20
>=20
> Regards
>=20
> Frantz Dhin, President Zynot Foundation
>=20
>=20
>=20
> ______________________________________________________________________
> _______________________________________________
> zynot-dev mailing list
> [email protected]
> http://lists.zynot.org/mailman/listinfo/zynot-dev

The new Congressmen say they're going to turn the government around. I
hope I don't get run over again.