upload to deken?

[umlaeute]

how about making bob available via deken?

[zealtv]

I will look into this.

Am I correct that since bop is just abstractions with no dependencies, I could upload to deken something that looks like this:

bop[v20250128].dek

and that would show up in search results across all OSes and ARCHs?

It does also contain a sample pack and the whole package totals about 30MB which may increase with later releases. Any considerations there?

[umlaeute]

Am I correct that since bop is just abstractions with no dependencies, I could upload to deken something that looks like this:

bop[v20250128].dek

yes.
however, i would strongly advise against using the date as is as the version. If you do want to use the date, please prefix it with 0. (or even 0.0.), so you have bop[v0.20250128].dek (resp bop[v0.0.20250128].dek)
the reason is that sometimes people change their minds about their versioning schema, and having very large numbers makes this practically impossible.

It does also contain a sample pack and the whole package totals about 30MB which may increase with later releases. Any considerations there?

not per se.

the VM that hosts the deken packages does indeed have limited storage, but it really all depends on how often you are going to do releases. (my stance is, that you shouldn't remove releases from puredata.info once uploaded; but if you keep uploading the same 30MB of samples every week, it's probably not a very good idea).

you should also make sure to not include the entire git history in the uploads (that is: remove any .git* files or directories before creating the package)

[zealtv]

Very helpful, thanks

…

On Tue, 28 Jan 2025, 10:16 pm umläute, ***@***.***> wrote: Am I correct that since bop is just abstractions with no dependencies, I could upload to deken something that looks like this: bop[v20250128].dek yes. however, i would strongly advise against using the date *as is* as the version. If you do want to use the date, please prefix it with 0. (or even 0.0.), so you have bop[v0.20250128].dek (resp bop[v0.0.20250128].dek) the reason is that sometimes people change their minds about their versioning schema, and having very large numbers makes this practically impossible. It does also contain a sample pack and the whole package totals about 30MB which may increase with later releases. Any considerations there? not per se. the VM that hosts the deken packages does indeed have limited storage, but it really all depends on how often you are going to do releases. (my stance is, that you shouldn't remove releases from puredata.info once uploaded; but if you keep uploading the same 30MB of samples every week, it's probably not a very good idea). you should also make sure to not include the entire git history in the uploads (that is: remove any .git* files or directories before creating the package) — Reply to this email directly, view it on GitHub <#48 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEGTTPOA7VB45OIFQFHTRT2M5RI3AVCNFSM6AAAAABWAAXBQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJYG4YDINBRGM> . You are receiving this because you commented.Message ID: ***@***.***>