Re: Changes to handling version numbers internally
От | Brook Milligan |
---|---|
Тема | Re: Changes to handling version numbers internally |
Дата | |
Msg-id | 200006301517.JAA05530@biology.nmsu.edu обсуждение исходный текст |
Ответ на | Changes to handling version numbers internally (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Two issues with the new versioning ideas: - The version number would be set in configure.in as in VERSION='1.2.3' - So, we have to change and autoconf that periodically, instead of just having a simple 'version.h' file that we vi? It doesn't sound to me like something that *belongs* in configure.in, as it is not required for any tests that configurerequires ... What about having a single file (e.g., VERSION) somewhere that contains the relevant information (e.g., it only contains 1.2.3). Any Makefiles that need it could cat the value into a make variable and use it; any C files that need it could include it as appropriate. Alternatively, though probably not so cleanly in some ways, configure itself could use the value to define a variable that would be propagated as needed (probably only Makefile.global and config.h). Another point: Right now I think we should set it to '7.1devel', later to '7.1b1', etc. It's really quite wrong to label it '7.1' alreadynow. I suggest a numbering sequence that is strictly orderable. This is really useful for the versioning of the NetBSD code, because the location of each version within a largaer sequence is immediately obvious. The sequence goes something like: trunk -+--> 1.4A ---> 1.4B ---> 1.4C ---> ... -+--> 1.5A ---> 1.5B ---> ... | | | | releases +--> 1.4Alpha ---> 1.4Beta ---> 1.4 +--> 1.5Alpha ---> 1.5Beta ---> 1.5 | | +--> ... ---> 1.4.1 ---> ... This may not exactly correspond to the NetBSD scheme, but the general points should be clear: the main trunk versions are incremented in a nicely sortable order whenever major interfaces change (corresponding presumably to our need for initdb), and the branches have a similar clear ordering. This seems preferable to using versions like 7.1devel or 7.1b1 which are less formalized and less sortable. Cheers, Brook
В списке pgsql-hackers по дате отправления: