/[gentoo]/xml/htdocs/proj/en/glep/glep-0054.txt

Diff of /xml/htdocs/proj/en/glep/glep-0054.txt

Parent Directory | Revision Log | View Patch Patch

Revision 1.2		Revision 1.5
1	GLEP: 54	1	GLEP: 54
2	Title: An "old-school" metastructure proposal with "boot for being a slacker" Part II	2	Title: scm package version suffix
3	Version: $Revision: 1.2 $	3	Version: $Revision: 1.5 $
4	Last-Modified: $Date: 2007/10/12 10:34:08 $	4	Last-Modified: $Date: 2008/01/06 02:08:59 $
5	Author: Alec Warner <antarus@gentoo.org>	5	Author: Piotr Jaroszyński <peper@gentoo.org>
6	Status: Final	6	Status: Draft
7	Type: Informational	7	Type: Standards Track
8	Content-Type: text/x-rst	8	Content-Type: text/x-rst
9	Created: 11-Oct-2007	9	Created: 09-Dec-2007
10	Replaces: 39
11	Requires: 39
12	Post-History: 11-Oct-2007	10	Post-History: 09-Dec-2007
13
14		11
15	Abstract	12	Abstract
16	========	13	========
17		14
18	This GLEP amends GLEP 39[#GLEP39]_. A new project must be announced	15	This GLEP proposes addition of a new special package version suffix - ``scm`` -
19	to the community prior to it's conception. The announcement should state	16	for ebuilds checking out source directly from a source code management system.
20	the project goals, the plan to achieve those goals, and any other information
21	deemed useful to the community by the person proposing a new project.
22
23		17
24	Motivation	18	Motivation
25	==========	19	==========
26		20
27	Projects were being started behind the scenes that people were not aware of;	21	Currently there is no standard way of identifying SCM ebuilds. Using 9999 as the
28	this included developers and users alike. It was thought important to notify	22	version is pretty common, but it is handled like any other ebuild and hence
29	the community of new projects. This also enables new projects to get valuable	23	portage cannot provide any additional features for packages with such a version.
30	feedback before getting to far into design and implementation.	24	Another way is adding a separate package with a -cvs suffix in its name, but
		25	that forces the author to use ``\|\| ( cat/pkg cat/pkg-cvs )`` dependencies. The
		26	closest to what is proposed in this GLEP is the ``cvs`` version part, but its
		27	implementation is of very limited use. It has strange comparison rules, no
		28	documentation, has been used sparingly (if ever) and has a misleading name.
		29
		30	The possibility for package managers to recognise SCM ebuilds would allow them
		31	to add features dedicated specially to said ebuilds. One such feature could be
		32	automatic re-installation of SCM packages once a day or week. Any
		33	specifications for such features are beyond the scope of this GLEP.
		34
		35	Specification
		36	=============
31		37
32		38
33	Rationale	39	``scm`` is a special suffix. It can be used on its own, but also in any other
34	=========	40	valid version spec, just before the place where revision would go. And just like
		41	revision it can be used only once in a version spec, e.g.:
35		42
36	We hope projects receiving feedback fare better in the long run with regards	43	* ``cat/pkg-1.0_alpha0-scm``
37	to general reception as well as meeting the goals set forth in their	44	* ``cat/pkg-1.0_alpha-scm``
38	announcement. We hope projects announced early get more volunteers by virtue	45	* ``cat/pkg-1.0-scm-r3``
39	of being announced and in the community's view.	46	* ``cat/pkg-1-scm``
		47	* ``cat/pkg-1-scm-r2``
		48	* ``cat/pkg-scm``
		49
		50	These package atoms are sorted in ascending order (see `Version Comparison`_).
		51
		52	Version Comparison
		53	==================
		54
		55	The addition of the scm suffix yields changes in version comparison:
		56
		57	* When comparing version components from left to right the scm component has the
		58	highest priority over other version components. Hence
		59	``pkg-1_alpha-r3 < pkg-1-scm``, 'scm' is greater than 'alpha-r3'.
		60	* Current suffixes with no number part no longer default to zero if they are
		61	followed by an scm suffix. If that's the case the number part is considered
		62	to be of a maximum value. Hence ``1_alpha2-scm < 1_alpha-scm``, but still
		63	``1_alpha == 1_alpha0``. The rationale behind this choice is to allow
		64	multiple branches. For instance imagine a package with an alpha branch
		65	and multiple scm releases, as the following: ``alpha-scm``,
		66	``alpha2-scm``, ``alpha3-scm`` and so forth. The desired outcome is
		67	for ``alpha-scm`` to be greater than all other branches of the same tree.
		68
		69	Example parsing:
		70
		71	* ``cat/pkg-scm > cat/pkg-1``
		72	When parsing from left to right the first difference is ``scm`` and
		73	``1``. ``cat/pkg-scm`` wins.
		74	* ``cat/pkg-1-scm > cat/pkg-1.0-scm``
		75	When parsing from left to right the first difference is ``scm`` and
		76	``0``. ``cat/pkg-1-scm`` wins.
		77	* ``cat/pkg-1_alpha-scm > cat/pkg-1_alpha1-scm``
		78	In the first package version ``alpha`` doesn't have a number part and
		79	is followed by an ``scm`` suffix, hence it is considered to have a maximum
		80	value as the number part. When parsing from left to right the first
		81	difference is the number part of the ``alpha`` suffix. Maximum value
		82	yielded by the following ``scm`` suffix wins with ``1``.
		83
		84	List of version specs in ascending order:
		85
		86	* ``1``
		87	* ``1.1-scm``
		88	* ``1.2_alpha-scm``
		89	* ``1.2_beta_p``
		90	* ``1.2_beta_p0-scm``
		91	* ``1.2_beta_p1-scm``
		92	* ``1.2_beta_p-scm``
		93	* ``1.2_beta1_p-scm``
		94	* ``1.2_beta10``
		95	* ``1.2_beta10_p1-scm``
		96	* ``1.2_beta10-scm``
		97	* ``1.2_beta-scm``
		98	* ``1.2``
		99	* ``1.2-scm``
		100	* ``1.2-scm-r1``
		101	* ``1-scm``
		102	* ``10``
		103	* ``scm``
		104	* ``scm-r3``
40		105
41		106
42	Backwards Compatibility	107	Backwards Compatibility
43	=======================	108	=======================
44		109
45	Projects already announced before 19-Oct-2006 are not affected. Since this	110	Portage versions prior to 2.1.2.12 (included in 2007.0) don't handle arbitrary
46	GLEP was authored nearly a year later, conceivably projects announced since	111	version suffixes and die during various tasks making portage hard or impossible
47	then should retroactively send mail regarding their goals and means to achieve	112	to use. Later versions just ignore them displaying warnings. Hence use of
48	them if they have not done so already; otherwise they would be in breach of	113	``scm`` suffixes in gentoo-x86 tree will probably have to wait till 2008.0
49	policy set in 2006.	114	release or later.
50
51
52	Specification
53	=============
54
55	New projects should send an Request For Comments mail to gentoo-dev (and
56	optionally gentoo-project) in order to received feedback from the Gentoo
57	community. Once the feedback has been received and changes incorportated into
58	the goals and design (if any), the project team should send a mail to
59	gentoo-dev-announce (and optionally gentoo-announce) regarding it's launch.
60
61	The contents of the announcements is left intentionally vague as to not
62	restrict the scope of projects, goals, and means. If announcement, projects,
63	goals, or means end up being terrible; the authors of this GLEP fully expect
64	the community to chew you out over it.
65
66	This GLEP does not empower the community to kill a new project, even if everyone
67	decides it sucks.
68
69		115
70	Copyright	116	Copyright
71	=========	117	=========
72		118
73	This document has been placed in the public domain.	119	This document has been placed in the public domain.
74		120
		121	.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :

 Legend:



Removed from v.1.2
 


changed lines


 
Added in v.1.5
 Legend:



Removed from v.1.2
 


changed lines


 
Added in v.1.5
-Removed from v.1.2
+Added in v.1.5

	ViewVC Help
Powered by ViewVC 1.1.13