On Fri, Nov 11, 2011 at 12:29 PM, Benjamin Kaduk <kaduk_at_mit.edu> wrote: > On Fri, 11 Nov 2011, Mehmet Erol Sanliturk wrote: > > Dear all , >> >> Instead of using Current and then renaming everything for a new version >> number , >> is it not possible to use the newest version number in place of Current >> when it is branched . >> >> Such a change will prevent unnecessary renaming problems . >> >> >> For everyone , it i very easy to understand that 10.0 is the latest , >> therefore the current one . >> >> The current may be used as a symbolic link to the newest version number , >> such as used by Debian . >> >> >> For example , for FreeBSD 9.0 RC1 , the ports directory name was >> >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ >> >> >> which is NOT available now , and >> >> >> pkg_add -r * >> >> is giving error about directory not found . >> >> >> This is preventing testing and / or using efforts . >> >> >> I know , it is possible to rename local link names , but >> everyone is not so much knowledgeable . >> > > I'm not sure I understand your proposal. > In a month (er, two. well, maybe three) when 9.0 is released, do you > propose that the svn HEAD be called: > (a) 10.0 > (b) 9-CURRENT > (c) CURRENT > (d) something else > > I do not realy care for either (a) or (b), since (a) would imply that the > version is not changing, even as incompatible KBI/ABI changes are made. > Likewise for (b), once the KBI/ABI changes, HEAD is decidedly no longer a > form of '9'. > > -Ben Kaduk > During development of Version 9 , the name of directory was ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ During the 9.0 Release RC1 , the above name was used . Before releasing the 9.0 Release RC2 , the above has been changed . This change has broke the links in 9.0 Release RC1 . When we look at the ftp sites ( including mirrors ) all of them has changed . This naming structure is requiring re-structuring all of the directories over all ftp , and other sites . This is a wasted effort . Instead of doing this , a scheme like the following may be used : Instead of using /*-9-Current/ , use 10.0 for current . Assume our main directory is the following : ftp://ftp.freebsd.org/pub/FreeBSD/ As next directory , use 8.1 , 8.2 , 9.0 for current . ftp://ftp.freebsd.org/pub/FreeBSD/8.1/ ftp://ftp.freebsd.org/pub/FreeBSD/8.2/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/ All of the directories , for example , ... ports ... release ... snapshot ... whatever is related to 8.2 , 9.0 will be under 8.2 or 9.0 , in such a way that nowhere else a directory with name , for example , 9.0 will exist ... For example : ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/ports/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/packages/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/snapshot/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/release/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/stable/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/handbook/ ftp://ftp.freebsd.org/pub/FreeBSD/9.0/amd64/doc/man/ .... Explain to the people that 9.0 is the "Development" branch , NOT for production use . A single sentence to learn . Another step may be to insert an explicit warning message into current motd file about "Development" status of 9.0 . When time comes to make a release of 9.0 , which a new development branch will be generated , take a copy of 9.0 , and rename this directory as 10.0 . By using suitable find/replace scripts , find all occurrences of 9.0 with strict match and replace them by 10.0 . After generating directory 10.0 , propagate it to mirrors . Please , notice that , NOTHING is changed for the 9.0 , and NOTHING is broken with respect to generation of a new branch , all over the world .... Then start to work on 10.0 ... Continue in that way . Apply the similar steps to 9.0 for 9.1 : Take a copy of 9.0 , rename it as 9.1 , ... Thank you very much . Mehmet Erol SanliturkReceived on Fri Nov 11 2011 - 17:33:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC