Re: deprecating contrib for PGXN
От | Magnus Hagander |
---|---|
Тема | Re: deprecating contrib for PGXN |
Дата | |
Msg-id | BANLkTi=kZ_XXCpB3=-PT4k39vmNUudACew@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: deprecating contrib for PGXN ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: deprecating contrib for PGXN
|
Список | pgsql-hackers |
On Wed, May 18, 2011 at 14:49, David E. Wheeler <david@kineticode.com> wrote: > 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. Does it support having both v 1.3.1 and v1.4.0 and v2.0.2 at the same time? I somehow got the idea that old versions were removed when I uploaded a new one, but I happy to be wrong :-) >> 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. Yeah, I don't see the problem if they *are* dependent. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: