On 01/14/16 09:15 AM, Alexander Pyhalov wrote:
Hi.
What do you think about naming conventions?
We currently have 2015.0.2.X package version to mark RELEASE_MAJOR and
UPDATENUM . I think we'll preserve them until new snapshot (which will
become 2016.0.0.X).
I think it is much better to have Release.X.Y..Z where Release is the
name of the OI snapshot that is supposedly to land into and replace /dev.
Also i don't see any point of having package names like
Packageversion.X.Y.Z but it is better to have
Release.X.Y.Z.Packageversion, because leaving package/program upstream
(or local) release version behind distribution release versions can help
installing older version back into OI if newer updated one has some
unresolved bug, to help kep quality level.
Question of OI hipster snapshot and release names and packages names are
connected with the plan
of landing into /dev and having delevopment and testing going on in both
hipster and /dev.
/dev can be made out of hipster snapshots, with more testing and not
including everything that is inside the hipster, due to quality control.
Hipster would continue out of that purged /dev, so that every current
hipster is the state of development in between two /dev releases, with
quality control purge at every /dev.
Re-adding purged packages and working on them can be done in hipster
after /dev.
It is just important that after first update of /dev , made out of
hipster, hipster development is made out of that new /dev , so that it
is more easy to update from one /dev to the next /dev , that most of
people outside use and send bug reports and RFEs for.
What about repository name?
Initially multiple repositories were created to avoid having
repositories with too many packages, as this slows down IPS.
Any repository name for hipster is good enough and having fresh built
hipster in the new year (all packages freshly rebuit) with new
repository name is a good workaround for slowing down of IPS.
Now we usually pkgsend/pkgrecv repository to temporary place and move
back. So I don't think /hipster-XXXX repositories are necessary or
convenient. Perhaps, it's a good idea to move repository to /hipster
and preserve it there?
We already had /hipster and I suppose there are instalaltions of
/hipster somewhere and that would open the case of testing updating form
/hipster to /hipster-2016...
I think that having per-year hipster repository with freshly compiled
and clean repository at the beginning of the year is best solution
because of IPS slowdowns after many changes.
If /dev is updated with hipster, then at that moment /hipster would
start being tortched and clean-built anyway, following /dev release in
between /dev's.
At that moment, hipster would be single place of development with no
reason to be named by-year, yes.
As I see it, To develop on OI, one would install from latest /dev ISO,
update to latest /dev release, change repository to /hipster, update and
get newest development environment en route to next /dev.
That way update from one /dev to the current state of hipster would be
test for the next /dev and keep it working.
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
