Hello!
Would it be possible for you to release future files with version information appended to the filenames?
jme.zip
doc.zip
jmetest.zip
Are better named
jme-1.0.zip
jmedocs-1.0.zip (prepend jme, maybe docS)
jmetest-1.0.zip
I manage quite a library repository (with Ant integrating a tool named "Ivy") and I spent quite some time figuring out I had accidentally used different releases' files…
Karsten
Its been discussed to include meta tags within the jar for versions, but nothing has been agreed.
I second that request. I was just thinking of that when I searched and found this thread. XD
Actually, the date would be even better (along with the version) Something like jme-1.0-MMDDYY.zip (e.g. jme-1.0-121407.zip)
duenez said:
Actually, the date would be even better (along with the version) Something like jme-1.0-MMDDYY.zip (e.g. jme-1.0-121407.zip)
My vote goes for that.
Shouldn't we use funny animal names like Java itself? jme-gorilla.zip, jme-orangutan.zip, jme-bonobo.zip…
just kidding
Landei said:
Shouldn't we use funny animal names like Java itself? jme-gorilla.zip, jme-orangutan.zip, jme-bonobo.zip...
:D just kidding :D
Best idea I heard today.. (well it's still early here ok?). Except we should use monkeys not apes :P
llama said:
Except we should use monkeys not apes :P
How pedantic! :P
But I actually like the idea of using Monkey code names for future releases :)
Where can I find former released files ? I mean I need the v1 files to go with JME-physics-networking (JME 1 and JME-physics 1)
(http://forum.captiveimagination.com)
Totally agree.
And I prefer version numbers instead of aliases, I may be less fancy but every little helps to keep brains relaxed.
Knowing which version of the library you are using and the differences among versions is helpful. However this makes programming very straightforward and boring and hence should be left to the beginners!
REAL programmers write their code to work with any version. This is easily accomplished by a simple system which uses code decompilers and heuristics analysis that drives hundreds of factories which emit thousands of wrappers that make your code compatible with any given version of any given library. Bonus points go to a system that allows swapping of different library versions at runtime in response to the user input.
You can take me out of the real programmers camp then
lex said:
...
REAL programmers write their code to work with any version. This is easily accomplished by a simple system which uses code decompilers and heuristics analysis that drives hundreds of factories which emit thousands of wrappers that make your code compatible with any given version of any given library. Bonus points go to a system that allows swapping of different library versions at runtime in response to the user input.
Pish!
Sorry, completely off topic I know; but I couldn't resist!
Gentleman Hal said:
But I actually like the idea of using Monkey code names for future releases :)
Of course how many developers are going to get really hungry during the jme-reeses release?
Now that the version number is 2, it might be time to adopt the idea.
Its a nice convenience.
Oh - and its Rhesus
The nightly build is for version one - havent done v2.
happy to do both, is it a good time to do v2 also or should I wait a while
theprism said:
Its been discussed to include meta tags within the jar for versions, but nothing has been agreed.
Should do both, but you're really bucking a good open source convention by not labelling distro files with the version.
blaine said:
theprism said:
Its been discussed to include meta tags within the jar for versions, but nothing has been agreed.
Should do both, but you're really bucking a good open source convention by not labelling distro files with the version.
Has been suggested and really want to go that route.
Personally I would like to see staggered versions 2.01, 2.02 etc, that way the filename would include the version number.
I just need the community to agree one way or other and to work with the decision
In fact - 2.0 is beta - so 1.* is still supported. When 2.0 is released then 1.* will be final and presume bugs wont be fixed in it.