[Catalog-sig] New classifiers for Plone

[M.-A. Lemburg]

Tarek Ziadé wrote:
> On Fri, Nov 18, 2011 at 8:17 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Alex Clark wrote:
>>> Hi,
>>>
>>> On 11/18/11 8:23 AM, M.-A. Lemburg wrote:
>>>> Alex Clark wrote:
>>>>> Hi all,
>>>>>
>>>>> There has been a discussion on distutils recently re: new trove classifiers for Plone. We have
>>>>> settled on asking for the following new trove classifiers to be added:
>>>>>
>>>>>
>>>>>     Framework :: Plone :: 3.3
>>>>>     Framework :: Plone :: 4.0
>>>>>     Framework :: Plone :: 4.1
>>>>>     Framework :: Plone :: 4.2
>>>>>     Framework :: Plone :: 4.3
>>>>>
>>>>> We will then encourage our add-on developers to use them in their add-ons, and implement new search
>>>>> functionality on http://plone.org/products accordingly.
>>>>>
>>>>> Any objections? If not, please feel free to add these at your earliest convenience.
>>>>
>>>> You should also include:
>>>>
>>>> Framework :: Plone
>>>> Framework :: Plone :: 3
>>>> Framework :: Plone :: 4
>>>>
>>>> to make the set complete.
>>>
>>>
>>> We actually don't want those, unless you want to use 4 instead of 4.0. Using 3 (or 3.0) does not
>>> help us, as we don't intend to classify add-ons for releases prior to egg-based Plone releases
>>> (starting at 3.2).
>>
>> Well, you don't, but users may want to browser PyPI and other similar
>> indexes based on products for Plone, Plone 3 and Plone 4.
>>
>> The reasoning behind using major release classifiers is that package
>> authors may now want to update the classifiers for their packages
>> every time you issue a new release (by making a new release of the
>> package).
>>
>> The unqualified category is needed for consistency with the other parent
>> categories in the trove index.
>>
>>> We also discussed keeping the list as small as possible on the other thread.
>>
>> The above just follows the same schema as used for Python itself:
> 
> 
> I understand the need for Python itself, but for Plone or <put a
> framework name here>, does that make sense to add/maintain in the
> Trove the framework versions ? that's an endless list to maintain, and
> it makes me think that maybe we should allow *custom* trove
> classifiers, so people can extend that list without having to ask
> additions in the main trove list all the time

While custom classifiers would be nice, you'd also end up with
inconsistencies, different naming for the same thing and lots
of typos.

Perhaps adding a limited form of such custom classifiers would
work out at least for some parts of the tree:

    If a::b is in the index, then qualifiers using a::b as prefix
    would also be accepted, e.g. a::b::c and a::b::c::d.

That way e.g. frameworks could start using subtrees that they manage
themselves.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 18 2011)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/