[PD] versions of libraries from extended in deken (was Different versions of iemguts library in Deken)

[Alexandre Torres Porres]

Well, I did check the versions and this is what I got... the ones I
couldn't find the version I marked as "not versioned"; and I think they
could just be "0.0.1" or something. The one thing I dont get is tof, I
couldn't find the version, but there's a new one in deken as 0.2.1, maybe
call it 0.2 then? But I wonder how that version name came up... here's
tof's git https://github.com/electrickery/pd-tof

cheers

*library*

*version*

adaptive

0.1

apple

0.2

arraysize

0.1

bassemu~

0.3.1

boids

1.1.2

bsaylor

0.1.1

chaos

0.2

comport

0.2

creb

0.9

cxc

0.5.2

cyclone

0.1alpha56

earplug~

0.2.1

ekext

0.1.1

ext13

0.17.2

extra

from pd 0.43 (do we really need this?)

flatgui

0.1

freeverb~

1.2

Gem

0.93.3

gem2pdp

0.7

ggee

0.26

hcs

0.2

hexloader

not versioned

hid

0.7.1

iem_adaptfilt

1.02

iem_ambi

not versioned

iem_bin_ambi

not versioned

iem_delay

not versioned

iem_roomsim

not versioned

iem_spec2

not versioned

iem_tab

not versioned

iem16

1.0

iemgui

not versioned

iemguts

0.1

iemlib

not versioned

iemmatrix

not versioned

iemnet

0.1

iemxmlrpc

not versioned

jasch_lib

not versioned

jmmmp

0.47

la-kitchen

not versioned

libdir

1.9

list-abs

0.1-1

log

0.1

mapping

0.2.1

markex

0.86

maxlib

1.5.5

mediasettings

0.1

mjlib

0.1.2

moocow

not versioned

moonlib

0.2.1

motex

1.1.5

mrpeach

0.1

net

0.1

nsend

not versioned

osc

0.2

oscx

0.3.1

pan

0.1.2

pd-wavelet

not versioned

pdcontainer

not versioned

pddp

0.2.1

pdlua

0.6

pdogg

0.25.2

pdp

0.12.7

pduino

0.5.1

pix_artoolkit

not versioned

pix_drum

not versioned

pix_fiducialtrack

not versioned

pix_mano

not versioned

plugin~

0.2.2

pmpd

0.9

purepd

0.1.1

rtc

4.1

sfruit

not versioned

sigpack

0.43

smlib

0.12.2

syslog

0.1

tclpd

0.3

testtools

0.1

timestretch

not versioned

tof

not versioned

unauthorized

0.1

vanilla

from pd 0.43 (do we really need this?)

vbap

1.0.3.2

windowing

0.1.1

zexy

2.2.4

2017-03-02 16:52 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

>
>
> 2017-03-02 16:14 GMT-03:00 IOhannes m zmölnig <zmoelnig at iem.at>:
>
>> On 03/02/2017 06:37 PM, Alexandre Torres Porres wrote:
>> > 2017-03-02 6:13 GMT-03:00 Roman Haefeli <reduzent at gmail.com>:
>> >
>> >>
>> >> I thought those are meant to be transitional
>> >> packages that don't receive any further maintenance.
>> >
>> >
>> > What do you mean? Some packages are being updated and have newer
>> versions,
>> > some are abandoned and only have this version from the last
>> *pd-extended*
>> > up there... but they're not all meant to be either in one group or
>> another,
>> > and basically anyone can work on an abandoned library and update/upload
>> a
>> > new version...
>>
>> i don't see how this workflow is hindered by the current state of affairs.
>>
>> >
>> > Well, if they differ in version, it's good to know which version it is,
>> if
>> > it's a newer version, an older version, the same version... I think it's
>> > really confusing if you do not know the version at all... you just can't
>> > compare! And you have to understand that most people looking at it
>> cannot
>> > really grasp the idea that the package is "from the last extended
>> package"
>> > - you can see the question from David as an example...
>>
>> the idea is very simple:
>> any package that gets uploaded, should have a version that is higher
>> that "0.0extended".
>> if they have a higher version number, then deken will sort them *before*.
>> the idea of deken is really: the very first link should be the version
>> you are looking for. all other links are either outdated versions or for
>> different architectures.
>>
>> any library that is maintained (as in: there is enough interest in it
>> that someone wants to do a fresh upload) *should* have a version number
>> attached to it. (even if it is just a date-based version).
>> practically all libraries *will* have a version that is higher than
>> 0.0extended.
>>
>> >
>> > Anyway, seems that deken can take any kind of information and display
>> it. I
>> > get it that it's nice to have a clue that it's from extended, so,
>> instead
>> > of "v0.0.extended" why not give it a proper version and also explicitly
>> say
>> > it's from pd extended? Example suggestion;
>> >
>> > instead of "*cyclone-v0-0extended*",
>> > it could be "*cyclone-v0.1alpha56-pd-extended*"
>> >
>> > would that be worse somehow?
>> >
>>
>> what's the point of adding "pd-extended" when you have a proper version
>> anyhow?
>>
>
> agree, no much point, but I was just trying to meet half way
>
>
>> but i think what roman tried to say is, that your energy could be spent
>> much better by uploading updated libraries into deken (with their
>> correct versions set), than beating a dead horse.
>> and if there are no updated versions, then there are no version numbers
>> to compare anyhow.
>>
>
> Not sure if that's what he meant, but what about the idea of changing the
> version name of libraries that we know have a proper version other than
> v0.0?
>
> cyclone is one of them... I'd rather cyclone would be listed as
> v0.1alpha56 instead of v0-0extended. and I can work on finding out other
> library versions as well. I can see some do not have a version at all,
> 'moocow' for instance. It only has a "svn" date... it doesn't have any
> newer library as well. So, for those, we can just keep it like that, it
> makes total sense to mark them as "0.0", and maybe if it ever gets any
> attention or updates, it can be versioned as "0.1" and whatever.
>
> Yeah, seems like a lot of energy to spend, but I don't have much
> programming skills, so, as a good latin american, I can offer my cheap
> manual labor for you people, it's fine.
>
> cheers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170303/8aafac51/attachment-0001.html>