*-devel ports

[Ryan Schmidt]

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.