From norkthedork at gmail.com Fri Mar 28 10:56:03 2014 From: norkthedork at gmail.com (DraugTheWhopper) Date: Fri, 28 Mar 2014 11:56:03 -0400 Subject: [crossfire] Version bump request? Message-ID: *Tap* *Tap* *Ahem* (Is this thing on?) Right, so assuming that this email gets to the intended place [crossfire], here's a request: is there any chance of getting a new official upstream release? So the story is as follows: I do no coding or developing, but know enough about Linux to run Debian Testing. However, the current upstream version of CF is 1.70.0, which as of a week ago, is about two years old. If i understand correctly, all trunk improvements since then are not in any official upstream release, therefore never get packaged for Debian, and so are not seen by the casual people who merely "apt-get dist-upgrade" occasionally. Is there a chance a version 1.70.x could be released periodically, or is there a 1.99 that could be packaged separately, or should someone just start packaging nightly builds as "crossfire-client-unstable"? Please pardon my ignorance and correct me as necessary. --Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinz5000 at gmail.com Sun Mar 30 09:06:32 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sun, 30 Mar 2014 09:06:32 -0500 Subject: [crossfire] Version bump request? In-Reply-To: References: Message-ID: <533824E8.3050807@gmail.com> On 03/28/2014 10:56, DraugTheWhopper wrote: > Right, so assuming that this email gets to the intended place > [crossfire], here's a request: is there any chance of getting a new > official upstream release? So the story is as follows: I do no coding or > developing, but know enough about Linux to run Debian Testing. However, > the current upstream version of CF is 1.70.0, which as of a week ago, is > about two years old. If i understand correctly, all trunk improvements > since then are not in any official upstream release, therefore never get > packaged for Debian, and so are not seen by the casual people who merely > "apt-get dist-upgrade" occasionally. Is there a chance a version 1.70.x > could be released periodically, or is there a 1.99 that could be > packaged separately, or should someone just start packaging nightly > builds as "crossfire-client-unstable"? Please pardon my ignorance and > correct me as necessary. Yes, I think it's about time that we cut a new release. Even something as minor as "1.70.1" would be good, because it would mean that the *many* fixes and improvements are accessible to package users. It might not even be a bad idea to cut a minor release every year or so on a schedule, because there's really not a lot of release engineering that has to be done. Right now the code seems stable and no massive changes are being planned. Is cutting a release feasible in the next week? Thanks, Kevin Zheng From nicolas.weeger at laposte.net Sun Mar 30 11:53:08 2014 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 30 Mar 2014 18:53:08 +0200 Subject: [crossfire] Version bump request? In-Reply-To: <533824E8.3050807@gmail.com> References: <533824E8.3050807@gmail.com> Message-ID: <201403301853.17525.nicolas.weeger@laposte.net> Hello. I agree on the need to do a release :) I can't guarantee I'll do a Windows packaged version though. Regards Nicolas Le dimanche 30 mars 2014 16:06:32, Kevin Zheng a ?crit : > On 03/28/2014 10:56, DraugTheWhopper wrote: > > Right, so assuming that this email gets to the intended place > > [crossfire], here's a request: is there any chance of getting a new > > official upstream release? So the story is as follows: I do no coding or > > developing, but know enough about Linux to run Debian Testing. However, > > the current upstream version of CF is 1.70.0, which as of a week ago, is > > about two years old. If i understand correctly, all trunk improvements > > since then are not in any official upstream release, therefore never get > > packaged for Debian, and so are not seen by the casual people who merely > > "apt-get dist-upgrade" occasionally. Is there a chance a version 1.70.x > > could be released periodically, or is there a 1.99 that could be > > packaged separately, or should someone just start packaging nightly > > builds as "crossfire-client-unstable"? Please pardon my ignorance and > > correct me as necessary. > > Yes, I think it's about time that we cut a new release. Even something > as minor as "1.70.1" would be good, because it would mean that the > *many* fixes and improvements are accessible to package users. > > It might not even be a bad idea to cut a minor release every year or so > on a schedule, because there's really not a lot of release engineering > that has to be done. > > Right now the code seems stable and no massive changes are being > planned. Is cutting a release feasible in the next week? > > Thanks, > Kevin Zheng > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Mon Mar 31 01:47:22 2014 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 30 Mar 2014 23:47:22 -0700 Subject: [crossfire] Version bump request? In-Reply-To: <533824E8.3050807@gmail.com> References: <533824E8.3050807@gmail.com> Message-ID: <53390F7A.3080301@sonic.net> On 03/30/14 07:06 AM, Kevin Zheng wrote: > On 03/28/2014 10:56, DraugTheWhopper wrote: >> Right, so assuming that this email gets to the intended place >> [crossfire], here's a request: is there any chance of getting a new >> official upstream release? So the story is as follows: I do no coding or >> developing, but know enough about Linux to run Debian Testing. However, >> the current upstream version of CF is 1.70.0, which as of a week ago, is >> about two years old. If i understand correctly, all trunk improvements >> since then are not in any official upstream release, therefore never get >> packaged for Debian, and so are not seen by the casual people who merely >> "apt-get dist-upgrade" occasionally. Is there a chance a version 1.70.x >> could be released periodically, or is there a 1.99 that could be >> packaged separately, or should someone just start packaging nightly >> builds as "crossfire-client-unstable"? Please pardon my ignorance and >> correct me as necessary. > > Yes, I think it's about time that we cut a new release. Even something > as minor as "1.70.1" would be good, because it would mean that the > *many* fixes and improvements are accessible to package users. I also agree that a release would be in order. I'd just call it 1.71 - there isn't really any reason to do a micro release - one could even argue that calling it 1.80 is reasonable, on the basis that as much has changed from now to the past 1.70 release as between 1.60 and 1.70. Note that the release numbers should not be seen as decimal places - a 1.100.0 release should be considered valid - in other words, a 2.00 release does not have to follow a 1.90 release. > > It might not even be a bad idea to cut a minor release every year or so > on a schedule, because there's really not a lot of release engineering > that has to be done. There used to be a schedule, but any such process requires that the person making the release have time to do it. Also, on some of those, I got people asking on why I'm doing a release then vs in a month, and that time based releases didn't make much sense, which sort of made me disinclined to do such time based/scheduled releases. In theory, anyone can be given release admin privs, and there isn't anything that prevents anyone from making a release (there are not any secret/private tools that I use). I'm pretty sure I wrote a wiki doc on the release process that describes all the steps. Now clearly, it does make some sense that releases be coordinated - if you have 5 people each making releases based on what they seem reasonable, the release process could become a real mess. > > Right now the code seems stable and no massive changes are being > planned. Is cutting a release feasible in the next week? Are you volunteering to make the release, or are you asking the person that typically makes releases (me) if I can make a release? My free time always seems to be disappearing in various ways, so hard for me to commit to being able to get a release done in the next week. From kevinz5000 at gmail.com Mon Mar 31 17:35:21 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Mon, 31 Mar 2014 17:35:21 -0500 Subject: [crossfire] Version bump request? In-Reply-To: <53390F7A.3080301@sonic.net> References: <533824E8.3050807@gmail.com> <53390F7A.3080301@sonic.net> Message-ID: <5339EDA9.6080201@gmail.com> On 03/31/2014 01:47, Mark Wedel wrote: > There used to be a schedule, but any such process requires that the > person making the release have time to do it. Also, on some of those, I > got people asking on why I'm doing a release then vs in a month, and > that time based releases didn't make much sense, which sort of made me > disinclined to do such time based/scheduled releases. A release schedule might be useful for things that are frequently updated in small pieces, such as arches and maps. To keep it in sync with the major/minor release cycle, only bump the 'micro' revision. That said, it would have limited usefulness because most people who run servers stick to a single revision or simply follow trunk. > In theory, anyone can be given release admin privs, and there isn't > anything that prevents anyone from making a release (there are not any > secret/private tools that I use). I'm pretty sure I wrote a wiki doc on > the release process that describes all the steps. Here they are: http://wiki.metalforge.net/doku.php/crossfire_release_guide http://wiki.metalforge.net/doku.php/crossfire_release_cycle > Now clearly, it does make some sense that releases be coordinated - if > you have 5 people each making releases based on what they seem > reasonable, the release process could become a real mess. > >> >> Right now the code seems stable and no massive changes are being >> planned. Is cutting a release feasible in the next week? > > Are you volunteering to make the release, or are you asking the person > that typically makes releases (me) if I can make a release? I'd gladly volunteer to work on release engineering. Thanks, Kevin Zheng From rick at tanners.org Mon Mar 31 17:43:11 2014 From: rick at tanners.org (Richard Tanner) Date: Mon, 31 Mar 2014 17:43:11 -0500 Subject: [crossfire] Version bump request? In-Reply-To: <53390F7A.3080301@sonic.net> References: <533824E8.3050807@gmail.com> <53390F7A.3080301@sonic.net> Message-ID: <5339EF7F.1060608@tanners.org> On 3/31/14 1:47 AM, Mark Wedel wrote: > > I'm pretty sure I wrote a wiki doc on > the release process that describes all the steps. Yes, it was documented at: http://wiki.metalforge.net/doku.php/crossfire_release_guide And some info on release numbers: http://wiki.metalforge.net/doku.php/crossfire_release_cycle As always.. updates, clarifications and updates are always welcome. From kevinz5000 at gmail.com Mon Mar 31 17:57:25 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Mon, 31 Mar 2014 17:57:25 -0500 Subject: [crossfire] 'svn:externals' pointers to stable/next/latest Message-ID: <5339F2D5.7090807@gmail.com> Hi there, A while ago I wrote to the list regarding the removal of svn:externals from the client source directory in Subversion. Now I would like to point at a few remaining external references in the repository. The 'stable', 'next', and 'latest' folders in the root were set up as links to other parts of the repository. In my opinion this is confusing and has outlived its usefulness, and should be removed. The 'next' branch currently points to 1.12.0, and is not documented on the wiki. 1.12.0 is ancient and only in active use on Metalforge. The name is misleading. The 'stable' branch currently points to 1.70.0, which makes sense. Keeping this seems logical. This makes updating a server checked out from the branch easy, although its usefulness still seems limited. The 'latest' branch contains a single pointer to gridarta, which probably deserves its own top-level external reference. According to the wiki, it's supposed to point to the trunk directories, but those paths never change so there it's only there for convenience. I'd like to know whether or not there are still people using these links. If not, I'd like to get rid of them. Thanks, Kevin Zheng