ports/143948: repo-copy requests in net-p2p

[Doug Barton]

>Number:         143948
>Category:       ports
>Synopsis:       repo-copy requests in net-p2p
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb 15 09:30:07 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Doug Barton
>Release:        FreeBSD 8.0-RC1 i386
>Organization:
AAAG
>Environment:
	DNA
>Description:
	repo-copy requests in net-p2p
>How-To-Repeat:
	Per the recent discussion in -ports regarding the rblibtorrent
	ports I'm submitting the following requests, all in ports/net-p2p:
	1. copy rblibtorrent-devel to libtorrent-rasterbar-14
	2. copy qbittorrent to qbittorrent-22

	In addition to those two I plan to introduce libtorrent-rasterbar-15
	which will initially have a -devel suffix (as will qbittorrent-22).
	The port for the 0.15 version is much simpler than the 0.14 version and
	shares little in common, which is why I'm not suggesting a repocopy,
	although if you want to do one anyway I won't argue.  :)

	I have already added deprecated/expiration to rblibtorrent and
	sharktorrent.

	Rationale:
	The name change is to reflect the actual name of the project, make
	the ports simpler, etc.

	After libtorrent-rasterbar 0.15 is released there will be 2 "stable"
	versions active (similar to how we have 6.x, 7.x, and 8.x). The
	qbittorrent ports that depend on this library can make use of either
	version, however I'm not sure about the other consumers of the
	0.14.x version (currently rblibtorrent-devel). Therefore it will be 
	necessary to maintain both versions in the tree for some period of
	time. There will also likely be a 0.16 devel version at some point
	not too long after 0.15 is released. 

	For qbittorrent the development model seems to be to move the "beta"
	version into release status, then immediately roll out the new beta.
	Tagging the directory name will make rolling the stable/devel versions
	easier in the future without requiring more repocopies.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: