Menu ▾ ▴

#223 Full version number in Files downloads

unspecified
closed
Vidar Hasfjord
Build (33)
1
2023-03-01
2023-02-28
Otto Liljalaakso
No

We use OWLNext in our application that is built with vcpkg. To make this work, we have written a vcpkg port for OWLNext.

However, the source code archives in the Files section currently have only two-part version numbers in their filenames. For us, it would be simpler if the filenames included the full three-part version number. For example, the archive for OWLNext 7.0.10 is currently "sources/owlnext-7.0.zip", whereas we would prefer it to be "sources/owlnext-7.0.10.zip".

The main problem here is that currently the content of "owlnext-7.0.zip" changes when a new release is made. Most projects use an approach where release download contents are static, and when the content changes, a new downloadable file is added. This model is simpler to understand, and less prone to accidentally mixing up two different releases. It is true that checksums already allow detecting such changes. Still, making them visible in the filenames as well would be good.

We understand that the Files section is somehow hooked up with OWLMaker (which we do not currently use), so there may be some additional complication there. If so, feel free to just turn down this request.

Discussion

  • Vidar Hasfjord

    Vidar Hasfjord - 2023-02-28

    Hi Otto,

    Cool to hear that OWLNext 7 is in use and even ported to a modern package manager! I would be very happy to add an entry for your application on our Application Showcase page. Just tell us a little bit about your application and its development, and include a screenshot.

    I fully agree we should start naming our source code archives with full three-part version numbers.

    The primary reason for the current naming practice has been to accumulate download statistics, for which naming stability has been convenient. However, this is a minor concern, and having better semantic naming is a more pressing issue. We recently decided to start following the SemVer standard for our releases (see news post), so it may be a good time to change our file naming practice to follow that standard as well.

    I am tempted to broaden the scope of this ticket to "Package manager support" and give you ownership — provided you are willing and able to contribute your packaging solution for OWLNext, of course. I don't know much about package managers, but as I understand it, they make library dependencies much easier to install and maintain for users. It would be great to have this new installation option in our Installation Guide, and perhaps also publish OWLNext in the public package archives, to make discoverability and installation really easy.

    Let me know what you think, and I will add you as a developer on the project, should you want to take on this task.

     

    Related

    News: 2023/01/state-of-owlnext--shifting-gears-to-8
    Wiki: OWLNext_Application_Showcase

  • Vidar Hasfjord

    Vidar Hasfjord - 2023-02-28
    • status: open --> pending
    • assigned_to: Vidar Hasfjord
    • labels: --> Build
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,18 +1,7 @@
-We use OWLNext in our application that is built with vcpkg.
-To make this work, we have written a vcpkg port for OWLNext.
-Currently, the downloads in SourceForge's Files section have only the first two version numbers.
-For us, it would be simpler if the downloads included the full version number.
-For example, the download for OWLNext 7.0.10 is currently `sources/owlnext-7.0.zip`,
-whereas we would prefer it to be `sources/owlnext-7.0.10.zip`.
+We use OWLNext in our application that is built with <tt>vcpkg</tt>. To make this work, we have written a <tt>vcpkg</tt> port for OWLNext.

-The main problem here is that  currently, the content of `owlnext-7.0.zip` changes when a new release is made.
-Most projects use an approach where release download contents are static,
-and when the content changes, a new downloadable file is added.
-This model is simpler to understand, and less prone to accidentally mixing up two different releases.
-It is true that checksums already allow detecting such changes.
-Still, making them visible in file names as well would be good.
+However, the source code archives in the [Files](https://sourceforge.net/projects/owlnext/files) section currently have only two-part version numbers in their filenames. For us, it would be simpler if the filenames included the full three-part version number. For example, the archive for OWLNext 7.0.10 is currently "sources/owlnext-7.0.zip", whereas we would prefer it to be "sources/owlnext-7.0.10.zip".

-We understand that the Files section is somehow hooked up with OWLMaker
-(which we do not currently use),
-so there may be some additional complication there.
-If so, feel free to just turn down this request.
+The main problem here is that  currently the content of "owlnext-7.0.zip" changes when a new release is made. Most projects use an approach where release download contents are static, and when the content changes, a new downloadable file is added. This model is simpler to understand, and less prone to accidentally mixing up two different releases. It is true that checksums already allow detecting such changes. Still, making them visible in the filenames as well would be good.
+
+We understand that the Files section is somehow hooked up with OWLMaker (which we do not currently use), so there may be some additional complication there. If so, feel free to just turn down this request.
     

    Last edit: Vidar Hasfjord 2023-02-28

  • Vidar Hasfjord

    Vidar Hasfjord - 2023-02-28

    As proposed, all of our source code and documentation archives now have full SemVer-compatible three-part version numbers. Version numbers and download links on our wiki [Main_Page] have been updated.

    The OWLMaker archive has also been updated to include the build number.

    None of this required any updates in the OWLMaker code. After simply updating the "files-readme.md" index file in the root of the Files section, the source code download feature and also the program update functionality both seem to handle the new filenames just fine.

     

    Related

    Wiki: Main_Page

  • Otto Liljalaakso

    Otto Liljalaakso - 2023-03-01

    Hello Vidar,

    Thank you for addressing the issue so quickly. Yes, we are interested having our application in the showcase. It happens that we are dealing with the same problem space as you project, Lima VVA: Our application is 3D-Win. Let me just check with marketing if they are ok with this, and prepare the materials.

    For adding OWLNext to package managers, the only one we can do anything about (albeit a major one) is vcpkg. We are preliminary interested in submitting our private vcpkg port to the official public repository. We still have to check how much work this would mean for us. I will get back to you when I know more.

     
    👍
    1

    Last edit: Otto Liljalaakso 2023-03-01

  • Vidar Hasfjord

    Vidar Hasfjord - 2023-03-01
    • status: pending --> closed
     

  • Vidar Hasfjord

    Vidar Hasfjord - 2023-03-01

    @oturpe wrote:

    Thank you for addressing the issue so quickly.

    Happy to! Thanks for reporting it.

    Yes, we are interested having our application in the showcase. [...] Let me just check with marketing if they are ok with this, and prepare the materials.

    Good! If you get permission, I will promptly add an entry.

    It happens that we are dealing with the same problem space as you project, Lima VVA: Our application is 3D-Win.

    Awesome! So cool that there is other software out there in this problem space, developed and still maintained on OWL/OWLNext! I've sent you a private message (using the "Send message" function on your profile page), on possible ways we may collaborate. Let me know if you did not receive it.

    For adding OWLNext to package managers, the only one we can do anything about (albeit a major one) is vcpkg. [...] I will get back to you when I know more.

    Having vcpkg support would be a great first step. I see it is supported in Visual Studio, so that could be very helpful for many users, I guess.

    PS. I will now close this ticket. If you want to go forward with official vcpkg support for OWLNext, then just create a new ticket.

     

Anonymous
Anonymous

Add attachments
Cancel