Package naming schema
Mon, 05/04/2009 - 04:35
I would suggest a package naming syntax as follows:
<package name>_<version_number>-<revision number>_<target_release>.ipkg
Package names are always completely lowercase. The software version syntax depends on the software maintainer. Package names cannot have underscores in their names.
Example: linkedlist_1.4-5_5.2.ipkg
which would mean:
- Software package: Linked List
- Software version: 1.4
- Package revision: 5
- Target release: V5R2
With this naming schema there can be multiple packages of the same package for different target releases in the same repository.
The client's target release would be stored in a config file.
If software was not packaged for all releases it is possible to install software for a release which is below one's own release (install package with release 5.3 and own release is 6.1).
Any ideas?
Mihael
Thu, 05/07/2009 - 15:50
#2
package version numbers for as400 software
Why not just have the revision number as part of the version number..
- Software package: Linked List
- Software version: 1.4
- Package revision: 5
- Target release: V5R2
Example: linkedlist_1.45_5.2.ipkg
it makes version tracking slightly easier as well?
Wed, 06/10/2009 - 08:12
#3
But what if the package
But what if the package maintainer "must"/want to fix something in the package (not necessarily something the original developer has done)?!
Package version 1.4 with Revision 5 => 1.45
New Package version 1.4 with Revision 6 => 1.46
But what if we have:
Package version 1.4 with Revision 9 => 1.49
New Package version 1.4 with Revision 10 => 1.410
That is a bit misleading. I think the version number and the revision number should be splitted. The revision number is not something the original developer will have access to.
Current Package version 1.4 (with Revision 5) => 1.4_5
New Package version 1.5 => 1.5_0
Revision is practically the version number of the package builder. The package builder may have to change part of the original source to have the software fit into the overall design of the package management software.
Just some ideas. Nothing written in stone.
FYI: I'm current working on a concept (draft).
Current weather
Roanoke, Virginia USA
- No data
- Temperature: 59 °F
- Wind: Calm
- Pressure: 1008 hPa
- Rel. Humidity: 88 %
- Visibility: 10 mi
Fri, 03/12/2010 - 11:54
Bunch of Twits
- adds 'Thievery Corporation' to his list of groovey background music to play while programming :) — 2 hours 3 min ago
- is watching very serious blokes playing plastic darts.... wtf is that all about? — 16 hours 46 min ago
- has discovered that his mighty hammer Mjölnir is missing. — 3 days 4 hours ago
- grabs a coffee and settles down for a day of post implementation checks, project closure and user documentation... bah! — 4 days 4 hours ago
- is about to embark on an IHOP pancake eating frenzy with the sprogs... — 5 days 3 hours ago
- just watching tv, a female marine running up a beach, teagan says 'i hope shes not wearing heels because thats hard' ;) — 5 days 16 hours ago
- saturday morning, determined to do no work today just gonna hang out with the kids, walk the mutts, watch movies and vejjjjjj... hurrah! — 6 days 1 hour ago
- is al about rpg3, rpg4, php, asp, IBMi, html, xml, wsdl's and any other acronyms I can think of.... — 1 week 12 hours ago
- is pretending to type something important to avoid listening to someone talking a load of codswallop. — 1 week 20 hours ago
- see... DOTnetnuke.... Microsoft products make my brain shout 'Uncle!' — 1 week 2 days ago
- 1 of 8
- ››
Who's online
There are currently 0 users and 31 guests online.
Not all packages have to be dependent on a target release. An example would be a package with files like documentation.
My opinion would be to not add the target release and have a naming schema like
<package name>_<version_number>-<revision number>.ipkg
Which would mean that this package can be installed on any system.
Ideas?
Mihael