Re: CMSP 23. Have a development version flag
-=| Graham Barr, Fri, Oct 09, 2009 at 09:20:37AM -0500 |=- On Oct 9, 2009, at 8:17 AM, Ricardo Signes wrote: * David Golden xda...@gmail.com [2009-10-09T07:52:45] 23. Have a development version flag Agreed. * Con: Development version'ness would not be determinable post- installation AdamKennedy Packlist 2.0? Agreed. The main use of development status seems to be control if the distribution is indexed as the latest released etc. So having a flag instead of the hackish way we use _ seems a benefit. +1 Getting rid of _ will simplify downstream handling of versions. Currently one has to dig into CHANGES in order to determine if 1.002_04 is a dev release after 1.002 or the fourth beta before 1.002. Not that I am all for packaging development releases downstream, but some times they fix bugs and are a necessary evil. -- dam signature.asc Description: Digital signature
Re: CMSP 23. Have a development version flag
* David Golden xda...@gmail.com [2009-10-09T07:52:45] 23. Have a development version flag Agreed. * Con: Development version'ness would not be determinable post-installation AdamKennedy Packlist 2.0? -- rjbs
Re: CMSP 23. Have a development version flag
David Golden wrote: 23. Have a development version flag * Con: Development version'ness would not be determinable post-installation AdamKennedy Correction to my earlier reply: If we have the META info available *easily* post installation (cf. 33), my vote becomes a +1. Steffen
Re: CMSP 23. Have a development version flag
On Oct 9, 2009, at 7:20 AM, Graham Barr wrote: Packlist 2.0? Agreed. The main use of development status seems to be control if the distribution is indexed as the latest released etc. So having a flag instead of the hackish way we use _ seems a benefit. +1 David
Re: CMSP 23. Have a development version flag
On Fri, Oct 9, 2009 at 10:41 AM, Steffen Mueller nj88ud...@sneakemail.com wrote: David Golden wrote: 23. Have a development version flag * Con: Development version'ness would not be determinable post-installation AdamKennedy Correction to my earlier reply: If we have the META info available *easily* post installation (cf. 33), my vote becomes a +1. That's the idea, which is why I'm in favor. Compared to a release_status field, this would be purely binary and thus not subject to people inventing new status categories. -- David