Re: deprecating contrib for PGXN

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: deprecating contrib for PGXN
Дата
Msg-id 77C3E437-D197-4BED-BF66-2635F12200CE@kineticode.com
обсуждение исходный текст
Ответ на Re: deprecating contrib for PGXN  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: deprecating contrib for PGXN  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On May 18, 2011, at 2:47 PM, Magnus Hagander wrote:

> I don't see why it couldn't, at least for a fair number of
> extensions.. It does require the ability to differentiate between
> patch releases and feature releases, though, which I believe is
> currently missing in pgxn (correct me if i'm wrong), but that's a
> solvable problem, no?

PGXN requires semantic versions. If authors use the correctly, then you can rely on the z in x.y.z to be a patch/bug
fixrelease, and the y and z to indicate new features. 

> Also, if it has several extensions, it should generate several DEB's -
> assuming they're independent extensions, right? If so, where's the
> problem?

Maybe they're not independent. But why is that a problem. There are a *lot* of DEBs with multiple Perl modules in them.

Best,

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: deprecating contrib for PGXN
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Why not install pgstattuple by default?