2008/2/5, js <[EMAIL PROTECTED]>: > On Feb 5, 2008 9:57 PM, Thomas de Grivel <[EMAIL PROTECTED]> wrote: > > 2008/2/4, Vincent Lefevre <[EMAIL PROTECTED]>: > > > On 2008-02-04 11:27:24 -0600, Ryan Schmidt wrote: > > > > 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 think this would be a good idea. > > > > > > > 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 > > > > > > AFAIK, tin-devel is no longer maintained (and perhaps no longer used). > > > > > > > Vincent's new proposals, "tin-devel" gets deleted and "tin-recent" gets > > > > renamed to "tin-latest", yes? > > > > > > +1 for this new policy. > > > > Then we would have to warn new users about -latest not being so stable > > because intuitively I would like the latest version to be installed > > but what retains me the the previous one is that "it just works". For > > the sake of stability I would have -unstable marked clearly, so that > > the users dont expect too much magic with -latest. > > I think -devel is better. > For one thing, it's more intuitive. > Second, this naming convension is already used in FreeBSD > so at least BSD users prefers -devel one. > > By the way, I think MacPorts is not for everyone, > I mean, it's mostly for developer or kinds of techies, right? > So IMHO providing an easy access to the latest, greatest software is > more important thant prevent users from using might-be-unstable-software. > Bad idea?
Of course, I did not mean to prevent anyone from doing anything ! Just make it the default if not proven unstable, or mark it as unstable (or devel) if it is. I agree with you that the latest version must be available by default, just what do you do when it is broken or breaks other ports or break the system ? Hey, I dont just hack programs, I also use them sometimes ^^; By the way, I'm a kind of a techie but I also often run into end-users who end up having macports installed by me because open source should be for everyone and I just wish they use it on their own and do not bug me (or you !) about it every time they install/upgrade something. Maybe we lack resources or feel like hackers but I'm sure we should definitely not deliberately make things unintuitive / uneasy. Vincent Lefevre <[EMAIL PROTECTED]> wrote: > On the other hand, the development version is sometimes less buggy > than the stable version. This is the case of mutt, zsh and lynx > (for which there have been recommendations to use the development > versions). Is there a reason for keeping an older version non-devel even when the -devel version is more stable ? Why not upgrade the default to the -devel version in this case ? My point of view is : have the latest version as the default, unless it is quite broken in some way, in this case make it a -devel version. Anyway, -devel should mean "for developers" right ? -- Thomas de Grivel (ps: replying above previous messages is totally unreadable, and don't quote the sigs ;) _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
