| 00:09.15 | alezakos | aren't you supposed to use compressed air to clean a computer? |
| 00:11.20 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 00:19.31 | blast007 | my computer always turns off when I throw the can in, though |
| 00:23.03 | Constitution | since mac is already changing the client version string layout for this release (possibly windows also?), would this release be a good time to standardize that format across all platforms and get all the info we've been wanting in there? |
| 00:23.28 | Constitution | there's been a todo for over 10 years saying "TODO add current platform, release, cpu, etc" |
| 00:24.09 | blast007 | the build system information, or the runtime system information? |
| 00:24.45 | Constitution | build... although for the data we would be mostly interested in, it would be the same |
| 00:25.05 | Constitution | and the target host in the case of cross-compiling |
| 00:28.22 | Constitution | I was thinking we could do the platform, 32/64-bit, and compiler in a standard format (hopefully autodetected), add the architecture, add or omit the debug designator consistently... and maybe drop the SDL indicator (mac always needs it, windows never uses it, and linux pretty much always uses it, so it seems superfluous) |
| 00:29.19 | Constitution | mac already puts the correct 32/64 bit indicator and xcode version in the client version string automatically |
| 00:29.22 | blast007 | I think it's useful to keep the SDL/SDL2 indicator since some issues are specific to SDL or non-SDL |
| 00:29.44 | BulletCatcher | 2.99 included more info about those things, but it turns out to be Hard (tm) to represent a meaningful set of info in just a few characters. |
| 00:30.29 | Constitution | I don't think linux builds currently put the "dbg" indicator in the version string |
| 00:31.16 | Constitution | SDL would be fine to keep... it is just going to get long... and have to figure out how to delineate with periods, hyphens, etc. consistently |
| 00:31.47 | Constitution | architecture would be nice, so everyone can ask me "what's mips?" ;) |
| 00:32.33 | Constitution | "an underpowered processor" |
| 00:32.52 | blast007 | BZFlag-2.4.4-2015-09-19-00-31-34-Windows-64-Debug-without-SDL |
| 00:33.38 | blast007 | I think 2.6 would be a time to standardize the build string, though |
| 00:34.40 | BulletCatcher | It might be more useful to replace the build date with the (presumably truncated) Git hash. |
| 00:35.04 | blast007 | BulletCatcher: that would also help with Debian's reproducable builds goal |
| 00:35.19 | BulletCatcher | That's what inspired the suggestion. :-) |
| 00:35.23 | blast007 | :) |
| 00:35.45 | allejo | likes the Git hash idea |
| 00:36.00 | blast007 | dunno how easy that is to extract, or how that affects the automatic source tar/zip generation on github, though |
| 00:36.00 | Constitution | mac already changed the version string format after 2.4.2... windows might have also... I seem to remember it was hardcoded to w32vc8 at one point... so to me the best time seems to be now |
| 00:37.06 | Constitution | the git hash is a cool idea, but extracting a meaningful number of characters would be roughly the same as the current date portion of the string |
| 00:37.28 | blast007 | that date is useless though, whereas the hash is useful |
| 00:37.50 | Constitution | true |
| 00:37.59 | blast007 | the date just says "I compiled some code on this day", where the has says "I compiled this specific code" |
| 00:38.09 | blast007 | hash* |
| 00:40.33 | BulletCatcher | I don't mind including various bits of info as long as we have a good reason for each of them. |
| 00:42.02 | blast007 | BZFlag-2.4.4-00111001110111000111 |
| 00:42.04 | blast007 | ducks |
| 00:42.06 | allejo | lol |
| 00:44.04 | Constitution | I would also just as soon we didn't have both STABLE and MAINT... I always thought anything that wasn't STABLE must be unstable when I first started :P |
| 00:44.43 | blast007 | should really just be NOTDEV since we're never stable ;) |
| 00:45.11 | allejo | what about HALFSTABLE, FULLSTABLE, SEMISTABLE? |
| 00:45.15 | Constitution | but you made us some unit tests :) |
| 00:45.41 | BulletCatcher | Using the Git hash would make that indicator completely redundant. |
| 00:49.53 | blast007 | I think the indicator is kinda pointless anyway, since our version numbers already imply it |
| 00:50.59 | BulletCatcher | It was important to JeffM, but not to anyone else as far as I could tell. |
| 00:52.00 | Constitution | so drop it? sounds good to me |
| 00:53.07 | Constitution | I think my poor 320 pixel wide screen is about to be outdone by this version string :P |
| 00:55.12 | BulletCatcher | We could just assign those semi-random images that GitHub and other sites use as distinct default avatars. :-) |
| 00:55.46 | allejo | identicons |
| 01:03.38 | *** join/#bzflag ploosma (~ploosma@184-96-203-161.hlrn.qwest.net) |
| 01:17.30 | Constitution | I'll throw together a draft spec |
| 01:39.09 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 03:09.56 | the_map | BZFlag-2.4.4-00111001110111000111 --> BZFlag-2.4.4-236999? is that a release? |
| 03:11.01 | allejo | it's the amount of lines bzflag has in total |
| 03:11.32 | the_map | ...I can't tell if you're serious or not |
| 03:14.55 | allejo | no, I'm allejo |
| 03:17.03 | the_map | your a grammar nazi (go ahead, correct me) |
| 03:17.24 | allejo | me).* |
| 03:27.46 | *** join/#bzflag bzbugsy (bzbugsy@2600:3c02::f03c:91ff:fe6e:ddc7) |
| 03:27.46 | *** join/#bzflag bzbugsy (bzbugsy@unaffiliated/bzbugsy) |
| 05:22.30 | *** join/#bzflag rodgort (~rodgort@105.ip-167-114-152.net) |
| 05:25.31 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 09:13.31 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 12:10.22 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 12:47.05 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 15:06.35 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
| 18:02.02 | *** join/#bzflag [Gort] (~gort@82-69-126-225.dsl.in-addr.zen.co.uk) |
| 18:02.02 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
| 19:27.43 | *** join/#bzflag [Gort] (~gort@82-69-126-225.dsl.in-addr.zen.co.uk) |
| 19:27.43 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
| 19:38.42 | *** join/#bzflag develCuy (~quassel@unaffiliated/develcuy) |
| 20:00.44 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.46) |
| 20:00.44 | BZnotify | [13bzflag] 15blast007 pushed 3 new commits to 062.4: 02http://git.io/vnGjw |
| 20:00.44 | BZnotify | 13bzflag/062.4 14d09447e 15Scott Wichser: Rename plugin README.txt files to be README.<pluginname>.txt format, and sample plugin configuration files to be <pluginname>.cfg format. |
| 20:00.44 | BZnotify | 13bzflag/062.4 14e51524f 15Scott Wichser: Use the new plugin README filenames, and copy any .txt files from plugins into the plugin output location.... |
| 20:00.44 | BZnotify | 13bzflag/062.4 14efe1063 15Scott Wichser: Remove copyplugindocs script. |
| 20:00.44 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.46) |
| 20:01.59 | Constitution | ~blast007++ |
| 20:03.22 | blast007 | I think the Xcode project still references README.txt |
| 20:05.34 | blast007 | gonna work on updating plugin README files now, getting rid of plugin changelogs, editing/removing plugin helpmsg files, etc |
| 20:14.44 | Constitution | should I wait until you are done, or are all the files at least in place? |
| 20:15.32 | blast007 | does Xcode reference any of the plugin changelogs or config files? if not, you could probably just go ahead - otherwise you could wait. |
| 20:15.50 | blast007 | (or any of the other .txt files from the plugins) |
| 20:16.44 | Constitution | I think just the READMEs |
| 20:17.51 | blast007 | I'm gonna make the Windows build and installer copy the .txt and .cfg files |
| 20:19.23 | Constitution | under a subdirectory for each plugin? right now Xcode just dumps all of the plugins into the Plug-Ins/ directory, kind of like autotools dumps them in lib/ |
| 20:20.39 | blast007 | I was just gonna dump them into the same location as the plugin binaries |
| 20:21.57 | blast007 | for autotools we could have them go into something like /usr/local/share/doc/bzflag/plugins |
| 20:22.24 | allejo | can we make sure 2.4.4 is distributed with functional .dylibs for OS X? I think 2.4.2 or 2.4.0 didn't have any functional ones |
| 20:22.44 | Constitution | will all the names be unique? it would be easy enough to dump them all in a directory under the .app package in mac, too |
| 20:22.54 | blast007 | yeah, that's the goal - unique names |
| 20:23.56 | Constitution | pfft allejo... what's the fun in that |
| 20:24.24 | allejo | :p |
| 20:25.54 | Constitution | this will be our first release under the native Xcode project... afaik plugins are working fine right now |
| 20:26.09 | allejo | cheers |
| 20:26.51 | blast007 | and I somehow broke unit test building on Windows ;D |
| 20:27.17 | blast007 | might just be a messed up cpputest build |
| 20:27.21 | allejo | I'm not the only one! |
| 20:27.56 | blast007 | there can only be one! |
| 20:34.31 | blast007 | ah, good ol' Windows firewall. Fire up the latest client, get the MOTD, the serverlist, join a server, watch it for a while, exit, and see a "Do you want bzflag.exe to be able to access the network?" .... |
| 20:38.03 | allejo | lol |
| 20:46.20 | the_map | so, the next release is going to be 2.4.4? |
| 20:47.47 | the_map | what is the difference between a 2.4.x release, a 2.x release, and a 2.x-->3.0 release? |
| 20:48.12 | allejo | a 2.x release breaks the protocol |
| 20:48.25 | allejo | so basically how 2.0.16 was not compatible with 2.4.0 servers |
| 20:49.11 | allejo | the way things worked were entirely different but a lot of the things still worked the same-ish |
| 20:49.28 | allejo | where a jump from 2.x to 3.0 would most likely entail a large rewrite of the code base |
| 20:49.44 | allejo | or significant new features and changes |
| 20:51.30 | allejo | and 2.4.x releases are maintenance releases meaning they're compatible with 2.4.x stuff. so it's all minor updates and fixes |
| 20:52.28 | the_map | so 2.4.4 will be compatible with anything 2.4.x, or only with 2.4.4? |
| 20:53.00 | allejo | a 2.4.4 client will still be able to connect to a bzflag server running 2.4.0 and vice versa |
| 20:53.36 | blast007 | if the first two numbers match, they are compatible |
| 20:54.15 | blast007 | well, unless the second number is odd |
| 20:54.58 | the_map | ? |
| 20:55.11 | the_map | why does even/odd matter? |
| 20:55.35 | blast007 | if the second is odd, it'a development version |
| 21:27.30 | the_map | thanks blast007, allejo |
| 21:58.39 | Constitution | here's my proposal for a new version string format: https://forums.bzflag.org/viewtopic.php?f=42&t=19110 |
| 22:07.14 | blast007 | "2.4.4.2b1a8f5c.embed-linux.mips.uclibc0.9.33.2-dbg-SDL2" wouldn't gcc still be the compiler, just using uclibc instead of glibc for the C library? |
| 22:10.23 | Constitution | hmm, yeah you're right |
| 22:12.47 | blast007 | and oss = 'Oracle Solaris Studio'? |
| 22:19.59 | Constitution | yeah |
| 22:21.25 | blast007 | I still vote to change it for 2.5/2.6, mainly so we don't have so many build strings to match in our MOTD upgrade messages |
| 22:22.41 | blast007 | I already need three to just to update all the 2.4 versions to 2.4.4 |
| 22:22.58 | blast007 | http://bzflag.org/motd.txt <-- this |
| 22:24.15 | blast007 | (and that still doesn't handle 2.4.1 dev builds if we care about that) |
| 22:24.38 | blast007 | oh, and what about marking specific builds as alpha, beta, and RC? |
| 22:25.46 | Constitution | I guess technically Xcode is an IDE, not a compiler... currently we have the Xcode version in the version string, but we could do something like "clang7.0.0" |
| 22:26.45 | Constitution | maybe put that right after the version? |
| 22:27.47 | blast007 | and for VC do we use the year, or the version number? For instance, 2010 = 10.0, 2013 = 12.0 |
| 22:28.01 | blast007 | and they only expose the version number as a define |
| 22:28.33 | blast007 | http://nadeausoftware.com/articles/2012/10/c_c_tip_how_detect_compiler_name_and_version_using_compiler_predefined_macros |
| 22:30.25 | Constitution | version number seems fine... I thought that's what the current number is supposed to represent |
| 22:39.17 | blast007 | 2.4.0 says "VC8" in the build string, but we were using Visual C++ 2008 at the time (version 9.0) |
| 22:39.41 | Constitution | IIRC it was hardcoded for a while |
| 22:40.20 | blast007 | it still is :P |
| 22:40.37 | Constitution | bleh |
| 22:40.56 | blast007 | defined in MSVC\build\config.h as BZ_BUILD_OS |
| 22:44.05 | Constitution | aren't we being overly optimistic to think that there will actually be a 2.6 release at this point? that was another reason I wanted to get it in on this one |
| 22:45.34 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 22:53.47 | blast007 | what else am I going to do with my free time? :P |
| 22:57.45 | kierra | Hmmm |