I think here we could use it up the idea of release codenames.
Now:
kernel-2.6.30.1-unity0.1
1-1
kernel-2.6.30.1-unity0.1-1-1-unity2009.i586.rpm
Should be:
kernel-2.6
2.6.30.1-unity0.1-1-1
kernel-2.6.30.1-unity0.1-1-1-unity.i586.rpm
If this is perfect solution, well... I think isn't. I say, look at this.
We call our devel release as alternate for example Pharao. Witch is better?
kernel-2.6.30.1-unity0.1-1-1-unity.i586.rpm
Kernel.unity-pharao-0.1.1.rpm
Why? I think using codenames will mean what is for, and you could fill inside more info, if we document it recently. So, at the end will be not call each rpm like this:
beverlyhills.9210-unity.newkernelversion-whatwearemadelatest.machinebuildtype.developmentversion.ilovenyorkdc.rpm.....
Hell too long, and really you could make mistakes, and mixing at naming conventions.
But, if you know that Pharao in name means:
- Main Development release, beta releases
- year 2009
- Build for i586
- Development for next stable release
- Only for testing purpose
Then you could simplify, and shorten the names.
Or if you call Playground the experimenting build, then you could call:
Kernel.unity-playground-0.1.1.rpm
Where playground means:
- Experimenting for next devel tree part, alpha releases
- possible release 2010
- Build what is in here descibed
- Possible faults
- Only for package builders, main designer developers
and so on. And if something changed, or build is for ARM, or RISC, then use it another name. When something couldn't be worked out, then the project will marked to be dropped in tree, and chooses an new name, with new means, and targets. With it each target maybe could have an experimental, an development and an stable tree - witch following each other. First experimental is alpha releases, witch is pushed to development beta, and after stable. Shortly, we must choose 3 names at begin.... With so, i think naming could be more precise. What do you say?