Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (541)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  how to increment software versions?  (Read 2031 times)
0 Members and 1 Guest are viewing this topic.
Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Posted 2012-12-19 22:19:00 »

Hello fellow java progammers! this might sound like a weird question but how do you guys increment your software versions? If you were just releasing a bug would u change it from 1 to 1.01 or something else? Or have any of you created a system for this? Any ideas are welcome!

Offline sproingie

JGO Kernel


Medals: 202



« Reply #1 - Posted 2012-12-19 22:21:08 »

It's just a filename for your jar.  Java has no concept of library or program versions.  It usually depends on your build software -- if you're using maven, you update the <version> in the POM.
Offline Varkas
« Reply #2 - Posted 2012-12-19 22:24:44 »

On Unix you often find schemes like <major>.<minor>.<patch> where patches are bug fixes, minor are minor changes, and major, well are major changes.

On Windows you often see something like <major>.<minor><a...z> where a-z denotes fixes, minor and major work just like above.

I've got tired of all that and just count releases. Starting with 001 and going up each times I publish a new version regardles how big or small the changes are ... often I write that as 0.01 but actually I just count releases these days.

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline wreed12345

JGO Knight


Medals: 25
Projects: 2
Exp: 2 years


http://linebylinecoding.blogspot.com/


« Reply #3 - Posted 2012-12-19 22:30:47 »

It's just a filename for your jar.  Java has no concept of library or program versions.  It usually depends on your build software -- if you're using maven, you update the <version> in the POM.

Lol not what i mean...

Offline alesky

Junior Devvie


Medals: 3
Exp: 15 years


mmm....


« Reply #4 - Posted 2012-12-19 23:21:11 »

so you mean:
how to allow to your application to verify if there are new version of your software and how to automatically download and update it?
Offline HeroesGraveDev

JGO Kernel


Medals: 325
Projects: 11
Exp: 3 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #5 - Posted 2012-12-19 23:36:23 »

1  
versionNumber++;


Grin

Offline actual

JGO Coder


Medals: 24



« Reply #6 - Posted 2012-12-20 02:04:18 »

Semantic Versioning is a standard someone proposed for versioning. I don't know how well it has taken hold but Google does give up some hits (as well as some stackoverflow question/answers). It makes sense to me, but it's overkill for what I need.

I think the key question is, who is the real audience for the version number? If it's just you banging away on your project, then I don't think version numbers are all that necessary and you can simply keep track of things through your version control tool (you are using version control, right? Right? RIGHT?!?!). Although I can see the mental component of slowly rising version numbers as a barometer of progress being motivating.
Offline deepthought
« Reply #7 - Posted 2012-12-20 02:09:50 »

whatever you want. right now i'm just on revisions because none of my stuff is truly out yet. A really good one would be to set it to a decimal representing how complete it is.

jocks rule the highschools. GEEKS RULE THE WORLD MWAHAHAHA!!
captain failure test game
Offline sproingie

JGO Kernel


Medals: 202



« Reply #8 - Posted 2012-12-20 02:46:38 »

Ah, I was thinking you meant it in some semantic sense, like "how do you make your program aware of the new version".  Sometimes I just read too much into questions Smiley

Anyway, my answer is, I use maven and sbt so I just update the version field in the build definition, by hand sometime before the next release.  I'm never all that good about doing it first thing after a new release, but no one notices because I don't release daily snapshots either.  I follow semantic versioning of major.minor.patch, which is more or less industry standard.  I do tend to draw a fuzzy line between "minor version" and "patch level", and don't use patchlevel that much, to be honest.  After accumulating enough bugfixes I just bump the minor version, since I like releases to always be on a .0 version.  If I have to deploy a patchlevel release into production, it's because something went seriously wrong that can't wait. 

Offline Grunnt

JGO Kernel


Medals: 95
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #9 - Posted 2012-12-20 10:15:24 »

I didnt yet include this in my build scripts, but one way is to generate a "build number" for each time you build (i.e. compile) the application. The application then shows this build number in the main menu or while starting up (e.g. "build 435"). Sometimes you release a new build, then it's clear for everyone involved what version the application precisely is, and whether they have the latest version (build number). I never understood the majorversion.minorversion.evenmoreminorversion.extremelyminorchangeversion approach to application version numbering. It's quite involved, prone to errors, and generally doesn't really say anything.

See: http://ant.apache.org/manual/Tasks/buildnumber.html for how to do this in Ant.

Edit: updated the link with better info.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #10 - Posted 2012-12-20 11:51:12 »

I have a manually updated number in an ant build script that I just increment, but I also export the svn revision number and burn that into the jar as well. The manual number covers 'big' changes and proper releases, the svn number is there so that I can easily see if someone's using a bug-fixed version or not. And also because sometimes I forget to update the manual number. Smiley

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline ReBirth
« Reply #11 - Posted 2012-12-20 11:54:20 »

I go with Varkas's, except it's <major>.<patch> since I rarely push new release with minor changes.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #12 - Posted 2012-12-20 15:47:03 »

I've got tired of all that and just count releases. Starting with 001 and going up each times I publish a new version regardles how big or small the changes are ... often I write that as 0.01 but actually I just count releases these days.

While I generally agree, when I was doing Tectonicus and suddenly ended up with loads of users, I found a major version number really handy. People generally understand that '0.xxx' means 'not quite finished and probably buggy'. And when I did a major breaking change that meant everyone had to change their config files and scripts etc. it was really handy being able to switch from 1.xxx to 2.xxx.

Other than the major version, the minor was just an incremented number as you say.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline appel

JGO Wizard


Medals: 69
Projects: 4


I always win!


« Reply #13 - Posted 2012-12-21 00:48:22 »

At work we like to use the mercurial hash tag for versioning information, because that way we can easily reconstruct the software from the versioning system. But of course we could assign something like "2.3.0" tag to it, but whatever.

Of course a string like "df894hfd9jl489d" makes no sense, because it doesn't indicate which version is more recent.

But IMO the format of the versioning doesn't matter as much as long as you can translate that to a certain version of your software, like in a versioning system. And also, using an incremental number is helpful for everyone.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #14 - Posted 2012-12-21 05:45:51 »

I just do it like this:

<major>.<minor>.<extra minor>

(extra minor is a thing that can not be called a minor change (if too small, for example)).

Smiley
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (10 views)
2014-12-27 04:03:04

TheDudeFromCI (13 views)
2014-12-27 02:14:49

Mr.CodeIt (25 views)
2014-12-23 03:34:11

rwatson462 (56 views)
2014-12-15 09:26:44

Mr.CodeIt (46 views)
2014-12-14 19:50:38

BurntPizza (92 views)
2014-12-09 22:41:13

BurntPizza (113 views)
2014-12-08 04:46:31

JscottyBieshaar (85 views)
2014-12-05 12:39:02

SHC (95 views)
2014-12-03 16:27:13

CopyableCougar4 (102 views)
2014-11-29 21:32:03
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!