versions of libraries from extended in deken (was Different versions of iemguts library in Deken)
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@gmail.com:
2017-03-02 16:14 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/02/2017 06:37 PM, Alexandre Torres Porres wrote:
2017-03-02 6:13 GMT-03:00 Roman Haefeli reduzent@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
On 03/03/2017 07:42 AM, Alexandre Torres Porres wrote:
Well, I did check the versions and this is what I got...
machine readable format?
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.
how's that better than "0.0.extended"?
2017-03-03 6:01 GMT-03:00 zmoelnig@iem.at:
machine readable format?
please explain what is and what do you mean by "machine readable format"?
2017-03-03 6:01 GMT-03:00 zmoelnig@iem.at:
On 03-03-17 07:42, Alexandre Torres Porres wrote:
could just be "0.0.1" or something.
how's that better than "0.0.extended"?
Well, how is it worse? And what would be better? It's hard to guess what is your issue and address it, but I'll try to further discuss it anyway.
First, for the sake of being accurate and clear, it's "*0-0extended*" and not "0.0.extended". So, are you suggesting a newer format? I'm guessing not, anyway...
Now, continuing the ealier thinking in response to Fred. I now think the "0.0.1" - as I had suggested - is weird cause I didn't find any library released as such in extended (and it'd be quite unlikely to happen so, right?). The smallest version number you can find is "0.1". So, instead of "0.0.1 or something" I could now suggest just "*0.1*" (with no "or something" anymore, "0.1" would be the "something").
But then, it's hard to debate cause I don't know where you're to get with your question... I thought that "0-0extended" was just a cheap solution because no one had volunteered to check their actual versions.
At least I hope it's clear why I think "0-0extended" is unfortunate, confusing and unclear, specially in respect to other libraries available - is it the same, newer, older? (I found duplicates, btw). We've had a question about exactly that in a previous thread: "how does the 0-0extended version of iemguts relate to the 0.2.1 available only for windows?". Now there's an answer...
Even if "0-0extended" is the only option there, most of them have versions that would just be good to know, without having someone dig through "meta.pd" or something. And in the case there's no versioning, 0.1 seems like a good place to start, and it would have made it easier fro Fred to work on an update of "tof", for instance.
cheers
2017-03-03 9:45 GMT-03:00 rolfm@dds.nl:
please keep the clarity of 0.0-extended version name.
Hi, I got your message separate from the others and missed it for a while, in another thread, I'm responding here so it's in the same thread for me...
Can you explain what you think is "clear" about the '0.0-extended' version name? I had some considerations as to how it's actually unclear (which I won't repeat yet again), so I wonder how does it work for you and how maybe we can find a solution that makes everyone happy.
I actually had proposed something else in another thread, I said it could still have the "extended" flag appended to the version. Would that work for you? I can actually see how a flag that explicitly tells you it's from extended might be desired for some people - I could go even further and suggest something like "pd-extended-0.43.4" as the appendment.
but IOhannes did question that idea, let me quote:
2017-03-02 16:14 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/02/2017 06:37 PM,
what's the point of adding "pd-extended" when you have a proper version
anyhow?
I said I was fine either way, and that I was just trying to meet in the middle with people that might want an explicit pd-extended label on the library
cheers
2017-03-03 13:29 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-03 6:01 GMT-03:00 zmoelnig@iem.at:
machine readable format?
please explain what is and what do you mean by "machine readable format"?
well, if the idea was a computer file, here's a google spreadsheet you can download in any format you want
https://docs.google.com/spreadsheets/d/1VBzQk7n1XgxTmOH83JHikokkOiIFe_9WQz-1...
libraries not versioned are postulated as "0.1", following Fred Jan's reasoning when working with 'tof'.
Anyway, I understand this is a major time consuming task, so how can I help? I'm really volunteering to better sort these libraries in deken.
cheers
On 03-03-17 07:42, Alexandre Torres Porres wrote:
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
I couldn't find a version number either, and having made some bug-fixes, a new version number was needed. So I postulated the original 0.1.0 and following the Pd standard of "major.minor.bugfix" I ended up at 0.2.1 (new version and a bug-fix).
The version from pd-extended then should be 0.1.0 but 0.0.extended will do too.
Fred Jan
2017-03-03 10:54 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
On 03-03-17 07:42, Alexandre Torres Porres wrote:
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
I couldn't find a version number either,
ok, I'm not crazy then (yet), good...
and having made some bug-fixes, a new version number was needed. So I
postulated the original 0.1.0 and following the Pd standard of "major.minor.bugfix" I ended up at 0.2.1 (new version and a bug-fix).
The version from pd-extended then should be 0.1.0 but 0.0.extended will do too.
I see, nice... yeah, numerous libraries in Pd extended are actually "0.1", and that seems to be what makes sense for a first release version. I did suggest "0.0.1" but that seems silly now to me, I like your reasoning better!
But then, "0-0extended" could be anything, the same, newer or older version... Now that I've done this work, I'm being able to find duplicated libraries uploaded to deken, I can see "v.0.0.extended" and then another upload with the same version as the "0.0" actually is (which I'm soon hoping to check what the difference is and fix if it's just really a duplicate).
This is why I think a better alternative to v.0.0.extended is needed, it gives you a clue where to start from if you're working on an update. And it is specially important if there is already another version uploaded there, as is the case of "tof".
cheers
-
Alexandre Torres Porres -
Fred Jan Kraan -
zmoelnig＠iem.at