Re: [wxCode-users] About site reworking

[Francesco M. <f18...@ya...>]

Hi,

>>ehm, *cough*
>>http://wxcode.sourceforge.net/components/paletteframe/index.html
>>  *cough*
> 
> 
> Heh, I didn't mean to pick on you. Thats fine, once we get a way for
> people to do it thats where people can put new ones.
yes, sure ;-)

> I also noticed that when you click on an item it tries to download this
> http://prdownloads.sourceforge.net/wxcode/<projectname>.tar.gz?download
> Is there some reasonable way to get a generic (not numbers) address
> for the "show only this release" for a component, like this.
> http://sourceforge.net/project/showfiles.php?group_id=51305&package_id=45182&release_id=257843
unfortunately, reading SF.net docs that's not possible...


> 
> If not, I think it'd be best to remove that (or just make it point to
> the cvs web dir so they can check it out before downloading) and just
> point them to this at the top of the page.
> http://sourceforge.net/project/showfiles.php?group_id=51305&package_id=45182
yes, I agree



> I hate having to download stuff that doesn't have any version info
> since you don't know what you got after a few months. Either that or
> you have to make up your own version for it.
That's true; without version info you cannot know if there is there was 
any change on the website... and I'd like to discuss this point: maybe 
some common rules for wxCode component 'versioning' could be created.
I actually was reluctant to use a version number for each component 
since they are so small... still I now think we should all use something 
like that.

Using three version numbers MAJOR.MINOR.RELEASE is the standard but 
usually it happens (at least to me) that such version string must be 
written in a lot of your project files (maybe 1 in the readme, 1 in the 
configure.in script, 1 in bakefile; they become already 3 files to edit 
for a new release !).
Since components are small & a dev does not want to loose much time 
about it (usually), it should be able to make a new release quickly and 
thus possibly we should have only a version string to edit.
Still, the user must be able to quickly find the version of the 
component he is actually using...

Actually I do not use for my components version strings but release 
dates. If the user sees that there is a fresher download on the website 
he knows he's using something old.
Still, this suffers from the same problem above; also dates are more 
annoying to use since it's easier to remember & handle version numbers.

Maybe that we should put a "version.txt" file in each component and keep 
up to date only that.
The PHP scripts of the website could scan these files and use them in 
the complist page to show to the user the last available version.

All the problems above reflect the fact that I don't have much 
experience in handling such things; in my bigger projects I usually 
write buggy script which scan some files and replace version numbers 
using SED but it would be very annoying if I had to do it also for 
wxCode components ;-)

Francesco Montorsi