Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
33 user(s) are online (13 user(s) are browsing Forums)

Members: 1
Guests: 32

FlynnTheAvatar, more...

Support us!

Headlines

 
  Register To Post  

Shared Object versions on os4depot...
Home away from home
Home away from home


See User information
I wonder if we could get abetter scheme inplace for handling shared objects on os4depot.

The default action when uploading a new version of a file seems to be to relace the old version, this generally works well for appliactions, but for libraries, particularly shared object based ones, this is not so helpful.

Typically with shared objects if the major version bumps the library is not compatable. So whilst replaceing 2.1 with 2.2 is fine replaceing it with 3.1 for example means that any application requiring the 2.x API no lonegr works.

As an example I just tried to test Frederick Wikstroms port of OpenJPEG 2.0.0 the binaries therein are dynamically linked and require libpng15 . I only had png12 installed so I got to os4depot, but I find that png15 was replace with png16 in december, and the old version isn't available any more.

This seems to be a bit of headache for a developer let alone a user!

Some might argue that the aplications needed sobjs should come bundled with all the ones they need but ts just adds bloat to archive sizees and will ultimatly increase space required on os4depot.


A scheme where the previous versions of libraries are archived and available would be very helpful IMHO.


Go to top
Re: Shared Object versions on os4depot...
Home away from home
Home away from home


See User information
Quote:
Typically with shared objects if the major version bumps the library is not compatable.

For my own programs, I put the major version number in the program name, and (more importantly) in the archive name too. (At least when I go past v1.x, e.g. FolderSync2) But I only increase major version numbers for complete rewrites (or if they are somehow incompatible with previous versions).

If all archives on OS4Depot, and SObjs on OS4, followed this convention, then you'd always have the latest revision of every major version (both on OS4Depot & within SOBJS: itself). At least if OS4Depot policy allowed this...

(Of course this won't work for programs that increase their major version number for arbitrary reasons (e.g. Firefox, assuming we ever got a working port), but in those cases the developer should have enough sense to not put the major version number in the archive name.)

Author of the PortablE programming language.
Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project