| |
jailbird
Registered: Dec 2001
Posts: 1578 |
Updating releases after initial upload
OK, maybe a one pixel change doesn't grants a new entry, but lately I've seen people updating their releases after fixing bugs and stuff, then deleting the old download link and adding a new one. So, up to that point, 2-3 different versions of the same release exists somewhere.
If f.e. a data file is revised to an executable, an update is logical and even a must, but in these particular cases the authors are changing the actual visual characteristics of their work:
CSDb Logo
Weightless Fish Floating over a Worm Infested Desert
Following the same logic, I could go back to my old stuff, change a pixel here and there, refurbish them to modern standards, silently update them, and no one would notice except for those who're really familiar with my works.
PBY & FatFrost, it's really nothing personal, I'm just wondering where's the line where we'd have to open a new entry for an updated release? |
|
... 15 posts hidden. Click here to view all posts....
|
| |
Zirias
Registered: Jan 2014
Posts: 48 |
This issue affects me: I got interested in registering here after I found my new tool mkd64 as well as a little demo (just something really small) I made, here on this site. Unfortunately, the demo had a release date of 2013 and "released-by" me, but the actual file was a version from 2006 I never released, but that was lying around in an SVN repo for many years without any work being done on it (no time).
So, after registering, I replaced that file by the one I really announced in december 2013 on lemon64 and forum64, also stating the reason for doing so in the comments. Well, I got some criticism for that. Personally, I don't consider the old unfinished version (only showing the main intended content, but not at all looking like initially planned) worth an entry on here.
Therefore:
- what's the policy about correcting such mistakes when the entry was made by somebody else and the metadata doesn't match the presented file?
- what makes a release a release? I thought for "releasing" nowadays I'd have to announce it some place related to the scene?
Thanks for clarification/thoughts on this. |
| |
Moloch
Registered: Jan 2002
Posts: 2925 |
I don't see anything about "48 hours" in this text, looks like an update to the text (and spell checking) are in order?
http://csdb.dk/help.php?section=rules
7. Managing information about Releases:
9. release entries should never be updated with "new" or "fixed" versions of the same release. new versions of a release should get separate entries which reflect the proper release date and other details. if we spot such silently "updated" releases we will undelete and/or create a separate release entry for them, so if you choose csdb as your release platform better double check that what you upload is actually what you want to release. in tribute to the "old school" retroactive "unreleasing" will not be tolerated. (this rule does not apply to replacing broken files with working ones, obviously we hope) |
| |
jailbird
Registered: Dec 2001
Posts: 1578 |
Quote: I don't see anything about "48 hours" in this text, looks like an update to the text (and spell checking) are in order?
http://csdb.dk/help.php?section=rules
7. Managing information about Releases:
9. release entries should never be updated with "new" or "fixed" versions of the same release. new versions of a release should get separate entries which reflect the proper release date and other details. if we spot such silently "updated" releases we will undelete and/or create a separate release entry for them, so if you choose csdb as your release platform better double check that what you upload is actually what you want to release. in tribute to the "old school" retroactive "unreleasing" will not be tolerated. (this rule does not apply to replacing broken files with working ones, obviously we hope)
Great, my doc reading capabilities are amazing as always.
Well then, that's it. The rules are quite clear: make sure the release you're uploading to CSDb is the utmost final version, or open a new entry if you've changed something, even a pixel.
I'd make this rule a bit more flexible if it was up to me, but I don't mind it this way either.
@Zirias: was your work available for download from an open SVN repo? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11359 |
Quote:I don't see anything about "48 hours" in this text
technically you are correct - that rules existed only for cracks so far (look "48h rule" in crack standards). simple reason being that it wasnt much of a problem with any other type of releases yet :) |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting Jailbird@Zirias: was your work available for download from an open SVN repo?
The one that got uploaded here was located on my private SVN server. I didn't configure any r/o access control. The link was never announced, but passed around privately to some people. That's what I meant: do you consider this a "release"?
Anyway, as there was no access control and no license, I'm of course fine with people grabbing and spreading it, but not claiming it to be a much more recent release (one I really did, announcing it on e.g. lemon64). The quoted rule here doesn't say anything about inconsistent entries done by others, accidentally. So what do you think? Should I really upload the old one, "fixing" the metadata, although I 1) think it's unfinished crap and 2) didn't really "release" it, so can't give an exact release date (other than "some day in 2006")? |
| |
spider-j
Registered: Oct 2004
Posts: 498 |
Zirias: I think you got this topic wrong. This topic is about people releasing stuff and changing the release shortly after.
You did everything correct. This is a database and everyone can and should change entries/information that are/is wrong. So of course the file that you released in 2013 belongs to the entry of that release with releasedate 2013. Personally I do not think that your WIP from 2006 is a release that belongs here. And if so: for sure in a seperate entry. |
| |
jailbird
Registered: Dec 2001
Posts: 1578 |
Quoting ZiriasThe one that got uploaded here was located on my private SVN server. I didn't configure any r/o access control. The link was never announced, but passed around privately to some people. That's what I meant: do you consider this a "release"?
No, since it wasn't you who uploaded it and you neither gave permission to anyone to spread your work.
However that gives me an idea! Now, as the game cracking scene is more or less nonexistent, maybe it's time to train and first release unfinished demos. Unlimited vectors? Y/N. I have quite a few effects from HCL, anyone interested in first hand orrie trading? :)
But seriously, the correct approach would be in your case, to explain the situation to one of the mods, remove the unfinished release from the database, and to open a new entry on CSDb when a proper, formal version is released.
Holding back or revoking unofficial versions of releases is quite common, e.g. look at the party versions of many demos. |
| |
Moloch
Registered: Jan 2002
Posts: 2925 |
Whether or not someone had his permission to spread the file doesn't matter, once its out there its released. There are tons of similar "don't spread" releases here in the database already.
I certainly understand your viewpoint but this is why you don't give people access before release. I think Tomcat learned that lesson the hard way last year when an unofficial NOS release was spread and entered here. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
@Moloch, when I have something lying around unprotected, it could even get indexed by google and of course nobody needs permission to spread it, as long as there's no license attached. The point is just that the entry was wrong -- the release date didn't match the file (off by 7 years!). As I didn't think the crappy WIP version would be interesting to anyone and got there by accident, I put the real 2013 file there. If I ever experience something like that again, I'll contact a mod instead. Thanks, Jailbird. |
| |
jailbird
Registered: Dec 2001
Posts: 1578 |
Quoting MolochWhether or not someone had his permission to spread the file doesn't matter, once its out there its released. There are tons of similar "don't spread" releases here in the database already.
Aren't those releases still on CSDb just because the authors never tried to get them down? What about the cracks of new(er) games which are not welcome/featured here for whatever reason?
Also wondering, aren't the releases protected under authors' rights? So an NTD would hold on steady grounds.
The disclaimer says:
Quote:Should you find something here which is in violation with copyright, personal data privacy or similar, feel free to contact us as admin[at]c64scene.net for immediate removal. |
| Previous - 1 | 2 | 3 - Next |
