Package naming schema
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
Forums:
field_vote:
target release independant packages
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
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
package version numbers for as400 software
Why not just have the revision number as part of the version number..
Example: linkedlist_1.45_5.2.ipkg
it makes version tracking slightly easier as well?
Why not just have the revision number as part of the version number..
Example: linkedlist_1.45_5.2.ipkg
it makes version tracking slightly easier as well?
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).
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).