Liane Praza wrote:
> 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.
Bart has a special hatred for putting the build number into the branch
version. I've never particularly understood that, but I'd want his input
here as well.
Remember that the numbering scheme we currently have is something Stephen
and I came up with in a two-minute hallway conversation. I don't have any
particular attachment to it, and I don't think anyone else should, either.
Under the current approach, what are the version numbers for:
- the last development build which is not promoted to Solaris Next
- the initial release build of Solaris Next
- the first patch to Solaris Next
- the first build of the development train of the release after Solaris
Next
I think there's an unavoidable seam at each release boundary, as we branch
off the release itself from the development train. That could be done as
the first build of the release if that works better. But I'm still pretty
sure there's a release train and a (or multiple) development trains, so I'm
not sure I understand your later comment that it would be otherwise.
> >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.
Why should renaming "entire" cause breakage?
> Mark told me the tag couldn't be relied upon. I'll try to dig up the
> reasoning.
I'd believe it; I'm not totally opposed to it, especially as there's
already a special changeset at the beginning of each build, which can now
simply be augmented to update the version file.
> >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?
Apparently, yes. I don't see the point in having an incorporation that
incorporates a single package. Any set of packages which need to be
constrained to a specific set of versions (such as those emitted by a
particular build) should certainly have an associated consolidation. But
that's because of the relationships between those packages. A package
can't have the same kind of relationship with itself.
And for that matter, even a nominal consolidation such as SFW probably
shouldn't have a single incorporation governing it, either. Right now, it
builds and delivers everything for every build, and while that continues, I
suppose it makes sense for it to have a single incorporation. But if and
when it starts building each component independently, on a base release,
that incorporation no longer makes sense. Why tie mutt and postgres to
each other?
That said, postgres itself needs to be thought of as a mini consolidation
which has its own incorporation. Same goes for php. Or Apache + PHP. I
think this space needs more thought than just a single blanket as we might
do now.
> 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.
As long as we have a mechanism and a protocol for making it automatic, then
I'm happy.
We might also want to nail down the scheme for the development group
packages. Something like developer/opensolaris/osnet-nevada (yes, there I
go again) @126, which is unincorporated, but depends on specific versions
of other incorporations such as the ones for ON and the appropriate subsets
of GNOME and SFW and whatever else we depend on.
Danek
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
