Matt.Ingenthron at Sun.COM wrote: > > Of course, the challenge here is that if we did drop the micro, or even > the minor and there was an incompatible change significant enough we'd > be breaking other people's code, we would find it harder to deliver the > micro release through a patch though. Other options would be to to fork > or reintroduce the more explicitly versioned path. The point here is > there is no control over when there is an incompatibility introduced.
Indeed, that is why it's so important to research the stability likelihood when deciding the versioning for each component. Of course ultimately all the code for these components is owned by communities outside this one so it is possible that a component with a perfect stability promise and record might tomorrow deliver a 3.4.5.1 which breaks every interface from 3.4.5.0.. at which point we'll have to fork something (code or packaging). Hopefully it won't happen too much. > Perhaps there's a good middle ground here somewhere? I read up on a I wouldn't call it a middle ground as much as choosing the versioning of each component based on its community. There won't be a single middle ground that works for everything. > for instance, someone could install OpenSolaris 12/09 and get the PHP > that was around back in 06/08. If they could (even in an 'unsupported' > fashion), then that would be a good thing since the monolithic approach > we have right now would be broken up. Keeping the old packages available is interesting and something I keep thinking about... IPS seems to keep old revisions so that's a possibility, though maybe the repository might not choose to archive everything.. > Presumably the opposite would be possible.... but I don't know. Could I > keep my OpenSolaris held back to 06/08 (if say, it weren't mine but I > was just using shared infrastructure) and I wanted the 12/09 PHP? That direction is less likely for too long.. that php-6.0 package is going to have dependencies on all kinds of future things which in turn pull in other unmet dependencies. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
