| |
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? |
|
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
according to csdb standards this is strictly forbidden. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11359 |
its ok when the change is trivial (like a stray pixel, or a typo in a scroller) and the change is made within 48h. |
| |
jailbird
Registered: Dec 2001
Posts: 1578 |
Quote: according to csdb standards this is strictly forbidden.
I've read the help/docs and can't say that I found anything related to this matter (except for the part dealing with re-releases of cracks).
Or is there some kind of an unwritten rule considering the issue? |
| |
jailbird
Registered: Dec 2001
Posts: 1578 |
Quote: its ok when the change is trivial (like a stray pixel, or a typo in a scroller) and the change is made within 48h.
I see, guess that's fair enough. |
| |
pby
Registered: Jan 2014
Posts: 3 |
Sorry, if I did something against the rules.
I only changed the preview picture and left both versions as prg files online here (I named the new version "updated" so everyone coud see which one was the original version - both versions are filed under the same release). I also announced the changes I made in the comments. I did not silently change anything. I just thought the suggestion of doing the image in full resolution (made in one of the comments) made sense so I wanted to add the pixels I lost using the wrong format. I might be wrong but in my eyes it wasn't a fundamental change of my work.
If it's against the rules I'll gladly delete the release so no version of it will bother anyone.
I'm a huge fan of this community and I appreciate the feedback here. To me it's a great help to get back at doing c64 gfx and to even evolve technically and get better with time. I had no intention to fake anything. I know my work has obvious flaws but with your help I'm ready to improve... |
| |
jailbird
Registered: Dec 2001
Posts: 1578 |
Quote: Sorry, if I did something against the rules.
I only changed the preview picture and left both versions as prg files online here (I named the new version "updated" so everyone coud see which one was the original version - both versions are filed under the same release). I also announced the changes I made in the comments. I did not silently change anything. I just thought the suggestion of doing the image in full resolution (made in one of the comments) made sense so I wanted to add the pixels I lost using the wrong format. I might be wrong but in my eyes it wasn't a fundamental change of my work.
If it's against the rules I'll gladly delete the release so no version of it will bother anyone.
I'm a huge fan of this community and I appreciate the feedback here. To me it's a great help to get back at doing c64 gfx and to even evolve technically and get better with time. I had no intention to fake anything. I know my work has obvious flaws but with your help I'm ready to improve...
PBY, as I said, don't take it personally. I've never said you or anyone else changed anything silently (I have seen that both you and FatFrost have noted the changes on the product page), just brought up the quiet update as a possibility that no one could track at the moment.
But basically, I was just interested what is the general approach about this matter.
I'm more than fine with Groepaz's view on it. |
| |
pby
Registered: Jan 2014
Posts: 3 |
no, I don't take it personally but since you brought it up I wanted to set clear that I'm not into silently updating anything (since not everyone reading this thread will go to the mentioned releases, how should they know?).
I agree that it sucks if people secretly changed their releases afterwards.
The other problem I see are the votes since no one could see what version the votes actually counted for.
I'll delete the updated version. There'll probably be a chance to rerelease it in a different form like a collection or a demo of some sort, so my work wasn't in vein ;-). |
| |
jailbird
Registered: Dec 2001
Posts: 1578 |
There are no rules clearly stating that updating a release is not allowed, so you don't have to delete anything. And just as Groepaz wrote, a trivial change (like a pixel on the wrong place) within 48h is just fine. |
| |
iAN CooG
Registered: May 2002
Posts: 3187 |
just create a v2 or updated version entry if it's done different days after the initial release. |
| |
pby
Registered: Jan 2014
Posts: 3 |
Since I added 4800 pixels (24x200) by changing the format that might be considered more than a trivial change... or bending Groepaz's guideline far too much. So I think it's better to keep the picture as it originally was...
I corrected a couple of bad (green and red) pixels a few hours after the initial upload too but I left that fixed version online of course (as the guideline clearly applies to fixes like that). Thanks for the clarification on that matter! |
| |
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. |
| |
soci
Registered: Sep 2003
Posts: 479 |
Submitted by MacGyver on 19 March 2014
Soci: Thanks! But again: New version - new CSDb release entry!
Ok, maybe next time I'll not forget this.
I have no problem with creating a new release in general. However it would be good to have "clone release" function which copies most of the constant release data like type, released by, credits, website, etc. which is otherwise a pain to re-enter. Then I would be less inclined to just add a new download instead. As a bonus the relationship between releases could be stored like older/newer versions. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11359 |
Quote:What about the cracks of new(er) games which are not welcome/featured here for whatever reason?
it has been tolerated to not have the files linked IF (and only if) they are publicly (!) available elsewhere, meaning one of the FTP sites listed in the rules. also in almost all of these cases, it was the cracking group itself who didnt provide a file - technically anyone who got the file could upload it to the entry in order to complete it.
and yes, this rule must be changed somehow, since TDD is no more accepting cracks, and none of the cracking groups managed and/or bothers to get a proper FTP online. |
| |
spider-j
Registered: Oct 2004
Posts: 498 |
Quoting Groepaztechnically anyone who got the file could upload it to the entry in order to complete it.
I don't think this works with locked entries.
Quote:and yes, this rule must be changed somehow, since TDD is no more accepting cracks, and none of the cracking groups managed and/or bothers to get a proper FTP online.
Since CSDb allows adding "not public" downloads, I'd appreciate if this option would be used instead of not uploading at all. |
| |
Romppainen
Account closed
Registered: Apr 2008
Posts: 40 |
Quoting spider-jSince CSDb allows adding "not public" downloads, I'd appreciate if this option would be used instead of not uploading at all.
+1, at least until proper FTP site is available again. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11359 |
Quote:I don't think this works with locked entries.
if an incomplete entry is locked, contact one of the trusted users or a moderator. incomplete entries shouldnt be locked in the first place :) (imho this locking bullshit should be removed completely, now that we have proper logging)
Quote:Since CSDb allows adding "not public" downloads, I'd appreciate if this option would be used instead of not uploading at all.
indeed - that was the intend more or less. (personally i dont see a reason for why not ALL downloads should be like that, but thats another thing) |
