I like the idea. Let us see what organically grows around the code base. Not every column in our temple complex will be corinthian.
On Feb 3, 2015, at 9:12 AM, Dennis E. Hamilton wrote: > +1 on no convenience binaries until there is stability and capacity for > support. > I do think one needs to keep this in mind in terms of organization for > builds and how releases are identified (and dependencies handled), but > only that. > > -----Original Message----- > From: jan i [mailto:[email protected]] > Sent: Tuesday, February 3, 2015 08:21 > To: [email protected]; [email protected] > Subject: Re: Support Policies for Corinthia releases > > On Tuesday, February 3, 2015, Dennis E. Hamilton <[email protected]> > wrote: > > [ ... ] >> It strikes me that it is important that any support policy be explicit. >> That is, when does/will support for a version end, what exceptions might >> there be, and for how long. >> >> It is also important to have an effective way for downstream users to know >> when the support life is/will end for a given release or related binaries, >> and to be able to know when a new release provides critical updates that >> may impact their usage. Some creativity may be needed for accomplishing >> effective notifications. > > Well for this project we might choose only to release source and avoid all > these problems, at least for a long time until DocFormat is stable. > > Some of us might outside the project provide convenience binaries. > > So in total I do not really see downstream users or binary releases before > DocFormat is stabilized. At the moment we do not have resources to support > that. > > [ ... ] >
