Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Harvey ! (Registered 2024-11-25) You are not logged in - nap
CSDb User Forums


Forums > CSDb Discussions > Updating releases after initial upload
2014-01-31 13:44
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....
 
2014-01-31 19:28
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.
2014-01-31 19:46
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 ;-).
2014-01-31 20:16
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.
2014-01-31 20:32
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.
2014-01-31 20:41
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!
2014-01-31 21:38
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.
2014-01-31 22:03
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)
2014-02-01 10:26
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?
2014-02-01 10:42
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 :)
2014-02-01 14:36
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")?
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Mike
Luca/FIRE
Twoflower/ΤRIΛD
kbs/Pht/Lxt
WVL/Xenon
KEF
REBEL 1/HF
Ghost/Quantum
Meikel aka ZUX/Sparks
Guests online: 153
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 The Demo Coder  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Wonderland XIV  (9.6)
10 Comaland 100%  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Triad  (9.2)
Top Webmasters
1 Slaygon  (9.6)
2 Perff  (9.6)
3 Morpheus  (9.5)
4 Sabbi  (9.5)
5 CreaMD  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.048 sec.