On Feb 4, 2008, at 08:56, Vincent Lefevre wrote:
On 2008-02-04 07:52:44 -0600, Ryan Schmidt wrote:
On Feb 4, 2008, at 06:51, js wrote:
What's happen after -devel port get officially released?
are they removed from svn?
Some maintainers do that. I think most just leave the -devel ports
around.
I think that both choices are a bad idea, i.e. that -devel ports are
a bad idea.
Ok, but we have them, and this thread wasn't really to debate that,
but to document the current status quo.
IMHO, there should be stable ports and "latest" ports; by
"latest", I mean with all the latest features (e.g. with the highest
version number): in general, this is a development version, but for
some periods of time, this can be (stable or not) releases, in which
case the stable port and the "latest" can sometimes be the same. This
is not a problem, and this avoids the user having to switch between
the stable and the -devel port; and there's no point to stay with an
outdated RC once the corresponding release has been done.
I have no objection to the idea that *-devel ports should be updated
to the latest stable version, if no later development version is
available. Should we make this policy? Portmgr? Anyone?
Regarding the suggestion to rename all *-devel ports to *-latest, in
light of the above change, the name "latest" would indeed seem to be
clearer. It would also remove any potential confusion with the RPM -
devel packages, which IMHO would be quite a good thing.
I guess this is as good a time as any to bring up the "tin" ports:
$ port search ^tin$ ^tin-
tin news/tin 1.8.3 A threaded
NNTP and spool based UseNet newsreader
tin-devel news/tin-devel 1.7.10 A threaded
NNTP and spool based UseNet newsreader
tin-recent news/tin-recent 1.9.2 A Usenet
newsreader
$
Now, ignore the version numbers shown for a minute. Based on comments
in the header of "tin-recent" (copied below), it seems to be the
maintainer's intention (hey, that's you, Vincent!) that "tin" is the
latest released version, "tin-devel" is the latest development
version, and "tin-recent" is the more recent of the two. It looks
like someone has updated tin-recent but forgotten to update tin-
devel. So, to match Vincent's new proposals, "tin-devel" gets deleted
and "tin-recent" gets renamed to "tin-latest", yes?
# The Tin development model is based on patchsets, as indicated in
# the doc/CHANGES file. There are:
# * stable patches, numbered ddd (001, 002, and so on), which are
# applied to the current stable branch, and in general, to the
# unstable branch too (i.e. when there is one and when this makes
# sense);
# * unstable patches (new features), numbered Uddd (U001, U002,
# and so on), which are applied to the unstable branch only.
# In general, at some point in the time, there are two currently
# supported branches: a stable branch (e.g. 1.6) and an unstable
# branch (e.g. 1.7). At some later point (i.e. after a feature
# freeze?), the development line (coming from the unstable branch)
# is regarded as stable; this leads to a new stable release (e.g.
# 1.8.0) and a new stable branch (e.g. 1.8). At this point, the
# old stable branch (e.g. 1.6) is abandonned. Then the new stable
# branch (1.8) gets stable patches as usual (fixes, translation
# updates...), leading to new stable releases (e.g. 1.8.1), which
# correspond to the latest unstable release (e.g. 1.7.10) + bug
# fixes. As soon as the first unstable patch (U001) needs to be
# applied, a new unstable branch (e.g. 1.9) is created (split from
# the current stable branch).
# Portfile update policy: Follow the development line as shown on
# <http://www.tin.org/history.html>, preferring unstable versions
# to stable ones when there is a split, i.e. stay on the right.
# The goal of this tin-recent port (as opposed to tin and tin-devel)
# is to have the highest upstream version (regarded as either stable
# or unstable), i.e. with the latest features, using a single port,
# thus benefiting from some port management features, such as those
# provided by "port outdated" and "port upgrade".
# For instance, if ports are updated as soon as tin versions are
# released:
# tin tin-devel tin-recent
# 1.6.2 1.7.9 1.7.9
# 1.6.2 1.7.10 1.7.10
# 1.8.0 1.7.10 1.8.0
# 1.8.1 1.7.10 1.8.1
# 1.8.1 1.9.0 1.9.0
# 1.8.1 1.9.1 1.9.1
# 1.8.2 1.9.1 1.9.1
# 1.8.3 1.9.2 1.9.2
# where:
# 1.7.9 = 1.7.8 + patches U040 to U045.
# 1.7.10 = 1.7.9 + patches U046 to U052.
# 1.8.0 = 1.7.10 + patches U053 to U056.
# 1.8.1 = 1.8.0 + patches 001 to 006.
# 1.9.0 = 1.8.1 + patches 007, 008 and U001.
# 1.9.1 = 1.9.0 + patches 009 and U002.
# 1.8.2 = 1.8.1 + patches 007 to 011.
# 1.8.3 = 1.8.2 + patches 012 to 018.
# 1.9.2 = 1.9.1 + patches 010 to 018 and U003 to U006.
# Said otherwise:
# 1.8.1 = 1.8.0 + patches 001 to 006.
# 1.9.0 = 1.8.0 + patches 001 to 008 and U001.
# 1.9.1 = 1.8.0 + patches 001 to 009 and U001 to U002.
# 1.8.2 = 1.8.0 + patches 001 to 011.
# 1.8.3 = 1.8.0 + patches 001 to 018.
# 1.9.2 = 1.8.0 + patches 001 to 018 and U001 to U006.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
