|
Notes |
|
|
|
|
I agree that the revision number is fragile and that it's probably a good idea to move away from it, but how can it go out of sync in a clean clone? |
|
|
|
(0002935)
|
|
Blzut3
|
|
2012-03-28 00:40
|
|
|
So you build from a clean clone as well? All I can tell you is if I build the tip I get the following: "src/svnrevision.h updated to revision 3414." The clone was done just a few minutes ago (using https), but just to be sure I ran hg pull and hg up -r tip. |
|
|
|
|
> So you build from a clean clone as well?
No, but my clone should be identical to the bitbucket repo. To confirm this I just made a clean clone and "hg identify -n" returns the same number for the clean one and the one that I use to build the binaries. Which hg version are you using? I'm using 2.1.1. (actually tortoisehg-2.3.1). |
|
|
|
(0002947)
|
|
Blzut3
|
2012-03-28 02:01
(edited on: 2012-03-28 02:11) |
|
Hmm, interesting. I pulled your latest changes and it said it updated to 3416. Then when I went to modify updaterevision.c for debug purposes it fixed itself and now reads the revision correctly. I have no idea what caused that to happen. But in any case I'm uploading a new build now. I'll check the OS X build once that's done.
Regardless, it seems this needs to be changed sooner rather than later.
Edit: The Mac OS X build was showing the wrong, lower number as well. Same procedure fixed it, didn't even touch hg.
|
|
|
|
(0002949)
|
|
Blzut3
|
|
2012-03-28 02:20
|
|
|
Added some information no how you would go about getting the information from Mercurial, don't really have time to personally fix updaterevision since I need to work on term projects for school. |
|
|
|
|
|
That looks promising. I'll look into it. |
|
|
|
|
|
I started to investigate this and think using 'hg log -r. --template "{date|hgdate}"' and running the first number this command returns through the localtime command will do the trick (I want to create a single number based in the date in the format YYYYMMDDHHMM). More on this when I have more time, hopefully tomorrow. |
|
|
|
(0002983)
|
|
Blzut3
|
|
2012-03-29 03:13
|
|
|
Storing the changeset hash as well would probably be a good idea. It would help verify the exact changeset used for those who care. (Particularly me since it might take awhile for me to get the Mac and 64-bit builds up depending on where I'm located when you do a release.) |
|
|
|
|
|
I finished a first implementation using the YYYYMMDDHHMM approach for the version string and using the hgdate number as version number. It's not very likely that two commits are made during the same minute the revision an official beta build uses. Do you still think we need the changeset hash? And if so, where should it be displayed? |
|
|
|
(0003035)
|
|
Blzut3
|
|
2012-03-30 02:23
|
|
I think the changeset hash would be much more convenient than looking through the logs for a commit that matches a given date (unless there's a good way to find it that I'm not aware of). I'm guessing you don't want to clutter the console with information most users don't care about, so I would suggest adding a "changeset" command or something that displays the changeset hash. (I would of course suggest also posting the changeset hash when you announce the builds.)
I would also suggest only using YYYYMMDD for the normally visible version number as it's unlikely that we'd produce two beta builds in the same day. It'd be less cluttered in appearance at least. The HHMM could be saved for the changeset command as well. |
|
|
|
|
A "changeset" command (possibly "version_info" is a little more self explanatory name) is a good idea.
> I would also suggest only using YYYYMMDD for the normally visible version number as it's unlikely that we'd produce two beta builds in the same day.
That's certainly true for the official beta builds. I often release several unofficial beta builds during one day though, this would make it harder to distinguish those. We can also (additionally) shorten the year to YY (or even just Y). |
|
|
|
|
|
I added the "version_info" command. |
|
|
|
(0003069)
|
|
Blzut3
|
|
2012-03-31 18:01
|
|
That works for me. I imagine you're not going to use the underscores in the package file names (SkullDev98e-20120331platform[-arch].[ext])? Just wondering if I need to change anything on skulltag.net.
I guess one other thing I worry about is how the version is reported in the query protocol. Right now Doomseeker will try to download "r2012_03_31 17:44" and accordingly try to put that into the SkullDev file name. |
|
|
|
|
|
I hope we can continue to use the same version string in the filenames and in the game itself. How about YYMMDD-HHMM instead of the current string? |
|
|
|
(0003071)
|
|
Blzut3
|
|
2012-03-31 18:40
|
|
|
Actually I just realized that Doomseeker's plugin is going to need updating no matter what since the revision is parsed to a unsigned short. So yes, that should work. (The space and the colon still need to be removed since they may cause needless headaches on some systems.) |
|
|
|
(0003101)
|
|
Torr Samaho
|
2012-04-01 22:37
(edited on: 2012-04-01 22:38) |
|
I shortened the string to YYMMDD-HHMM and hope we can keep it like this. Are any changes necessary on skulltag.net if the new build archives have names like SkullDev98e-120401-2003windows.zip?
|
|
|
|
(0003104)
|
|
Blzut3
|
|
2012-04-01 22:42
|
|
|
Took a quick look at the script and it appears right now it will show up as r120401, but it might also not display the downloads. I'll get it fixed once you have a release up. In the mean time if it doesn't work you can just put the links in the thread. |
|
|
|
|
> In the mean time if it doesn't work you can just put the links in the thread.
Ok. |
|
|
|
|
|
Everything seems to be working fine now -> resolved. |
|