OpenEuphoria

1. The Archive and 4.0

• Posted by jeremy (admin) Mar 19, 2009
• 919 views

I have talked with Rob and Junko and Junko is willing to update The Archive script to contain some type of version status. We just need to decide what we actually want (within reason of course) and submit that to Junko. Here are some thoughts I have to get the discussion moving:

We could have checkboxes for version compatibility:

[ ] 3.0    [X] 3.1    [X] 4.0   [ ] 4.1   [ ] 4.2 

The problem there is what happens when we get to 5.0, 6.0, etc... That would begin to take up quite a lot of room?

We could have a free form text field:

Version Compatibility: [_____________________________________] 

People could enter text such as >= 3.0, 4.x, 5.x. The problem there is that if it is free form, people will do different things and make it hard to search.

We could have a minimum version number and maximum version number combo boxes (my favourite so far)

Min Ver: [3.0.1  |^]   Max Ver: [3.1  |^] 

The problem with that is you loose some fine grain control, for instance, what if it works in 3.0.1, 3.1 but 4.0 had a bug causing it not to function, but that bug was fixed in 4.0.1. Thus, your min version and max version says 3.0.1 -> 4.0.1, which includes 4.0 that it is known not to work in. Now, why this is my favourite so far is that I think the previous case will occur very rarely (hopefully never) and this idea, I think, will be easy to develop and maintain. All Junk has to do is add 2 fields to the current setup and give us a way to add new version numbers to the list.

Now, we run across one more problem... As said in the 4.0 Status thread, what about packages that no longer have an active maintainer. Let's say John Doe's package works great in 4.0, but he hasn't been seen for 5 years now. Who has the right to update that packages status? Can any registered user update the package compatibility flags? That would be my vote, as it can then be a huge group effort to get The Archive status updated. Another possible method is if during these updates to The Archive script, we can borrow functionality from ArchLinux's User Repository (user maintained packages). There, users have the ability to "Abandon" a package, making it free for the wild. Then a user can "Adopt" a package. Further, a user can request a "Take-Over" in the case that John Doe did leave and a package is out of date. Before a "Take-Over" can occur, the original author has to be contacted and given so many days, weeks to respond. They can either respond and "Abandon" the package if they do not want to manage it any longer, or respond and say "I'll update it myself, the package is still of interest to me, thanks for letting me know it's outdated." or simply not respond, in which the package will be given to that person who has requested it.

The benefit to the Abandon, Adopt, Take-Over method is that we are already sort of that way. Each package already has an owner. The other benefit is it keeps someone assigned to the package, maybe if for no other reason than to keep it updated to work in new versions of Euphoria, or to simply state that this package only works in 3.x (there are going to be many packages that are obsoleted by 4.0, due to it's new standard library. There will be no reason to make some of them work in 4.0).

The downside is that maybe people will not be as likely to update version information if they know that their name will then be attached to the file as maintainer. Maybe we need a combination of the two methods, or a totally new one that you think up

About maintaining versions for 3.x, 4.x, 5.x... Maybe instead of including a 3.x and 4.x directory in your .zip file, when you upload a new copy, if it's version attributes do not overlap previous ones, then it is considered a new file for that project. For instance, say there is a abc.e that does something really cool. It has a version for 2.5. You adopt it, update it to work in 2.5, 3.0 and 3.1. However, when it get's to 4.0, you make some really cool additions to it that was made possible by the standard library, or because of enums in 4.0, or some other feature. Now you upload a new script that the version flag is set to 4.0 only. Well, there is no overlap, thus, the system says this is the same package, but it should be a new file. The page may now look like:

Library: abc.e 
Description: Does something really cool. 
Files: 
    2.5 - 3.1.1      abc_25_311.zip       Updated: 03/20/2008    [ Download ] 
    4.0 - 4.0.1      abc_400_401.zip      Updated: 02/12/2009    [ Download ] 

These are my thoughts on The Archive. Please let the discussion begin!

Jeremy

3. Re: The Archive and 4.0

• Posted by mattlewis (admin) Mar 19, 2009
• 866 views

I suspect he meant in an interface. Presumably, the versions would be a lookup table, and there'd be a link table to allow a many to many relationship between contributions and versions.

Matt

5. Re: The Archive and 4.0

• Posted by gbonvehi Mar 19, 2009
• 885 views

Jeremy, this may be easier than you think. When submitting a file, you could have checkboxes to select the compatible versions. When showing the files to the user, they could be concatenated to form something like 3.0, 3.1, 4.0. If the versions are consecutive, you could use string or character to denote that, like 3.0 ~ 4.0 or 3.0 .. 4.0.

Cheers,

7. Re: The Archive and 4.0

• Posted by mattlewis (admin) Mar 21, 2009
• 806 views

I'm not sure why you brought up GPL. Many libraries don't mention anything about their license. Win32lib is basically released under the zlib license, which is certainly open, and has fewer restrictions on what you can do with the code than the GPL does.

Matt