Danek Duvall wrote:
Liane Praza wrote:
- Consolidations are expected to publish an appropriate version
number for each IPS package every time it is published. The
build number should increment as soon as a build opens.
The version number is part of the package FMRI after the @.
For OpenSolaris specific software, it should be:
0.5.11,5.11-0.<build #>
e.g.
0.5.11,5.11-0.127
I'm not sure that we really want to continue this numbering scheme. The
"0.5.11" was just a stopgap to make sure that we could move forward to any
reasonable version once we decided what the version actually should be.
Probably for Solaris Next, it should be "5.11". The question then becomes
how to number the versions leading up to a known version. Options include
- using an arbitrarily high number on top of the previous version:
5.10.99.127
- using a magic "negative" number to indicate it's prior to the
version: 5.11.b127
- using completely different package names
Hang on. You're implicitly proposing something quite radical: that
everyone would need to produce a "special" build at the end of the release
just to fix up the numbering. I'm not convinced that's the right approach
at all, and don't currently see the benefits in changing the process to
make that happen.
You don't talk much about what the consolidation incorporations should be
called. Presumably, they should be kept in a single portion of the package
namespace hierarchy.
That's fair.
Also, I was thinking that we could use a different
version space for the incorporations:
consolidation/osnet-nev...@127
That is, indicate the development version of the OS in the package name,
and simply have the build number as the major component of the release
version. The non-development version would be
consolidation/[email protected]
and either one could get dot and dotdot versions added for patches,
respins, etc. When Nevada development was over, osnet-nevada could be
renamed to osnet-whatever, if we assumed that folks would want to continue
on the development train, or simply to [email protected] if we thought they wanted
to move to release.
Again, I don't understand this "non-development" version you speak of. :)
The "entire" package needs to be renamed, probably to "solaris", and it
should follow the same rules as the ones above for the consolidations.
I won't be surprised to hear that doing this causes breakage, but yes,
"entire" has always been opaque.
There's also the question of what to do about "redistributable" -- that is,
the "get me everything" packages corresponding to the consolidation
incorporations. Perhaps we want to ditch that package entirely and have a
flag to "pkg install" that treats incorporate dependencies in the packages
on the commandline as require dependencies for that one operation:
pkg install consolidation/osnet-nev...@127
constrains your ON packages to build 127, while
pkg install -a consolidation/osnet-nev...@127
installs all of the build 127 ON bits?
That seems like a lovely addition to me. It's certainly easy to generate
a group package at the same time as generating an incorporation (since
both should be done automatically), but not having to do so is nice.
- ON will track the build number via a file in the repository
which the gatekeepers integrate as soon as a build opens.
i.e. when 127 opens, they push a change to say that the build
is 127. (usr/src/VERSION ?)
This can be done in the same changeset as the build tag. Though if the the
build tag is well named, the build could infer the build number from the
latest build tag. Perhaps that's too magical. And it doesn't take into
account the rest of the version number ("5.11").
Mark told me the tag couldn't be relied upon. I'll try to dig up the
reasoning.
- SUNWonbld is special. It's expected to be able to move
independently of the rest of the system, and is tested with
this in mind. Thus, ON will also deliver an incorporation for
SUNWonbld and not include SUNWonbld in the normal ON
incorporation.
I don't understand what that means -- why would you create an incorporation
that incorporates just a single package? Or are you missing a "not" before
"deliver"?
Do you disagree with the rule that everything a consolidation delivers to
RE should be governed by an incorporation?
- A cross-consolidation flag day is managed by requiring
developers track multiple consolidations for a single build.
Why wouldn't this be done by having one consolidation's incorporation have
a dependency (optional, or possibly require) on the other's at a particular
version?
Sure, that's a nice-to-have which makes crossing the flag day mandatory
through the software. It doesn't change the fact that in order to satisfy
the dependency, the developer will need to get access to the updated
packages from the other consolidation.
liane
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
