Home   Info   DevZone   Wiki  
UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ CodingConventionTalk ] [ not logged in ] [ Web: Imported ] goto:  options
[ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

I'd propose: just plain ASCII and not on the site... Code tends to grow large and I think we're better off having our code on FTP.

Second, I think we should assign each piece of code to a maintainer who does manage the diffs etc... I think editing code on Wiki will not work......

-- JeroenVanGelderen

We are just talking about different possibilities right now.

Page created by ChrisSmith

Versioning proposal: each version consists of jjjj.mm.dds where:

For instance my MD5 class is now at 1997.12.16b. It makes assigning, maintaining and comparing versions a snap.

I also propose that all alpha and beta release be time limited. This prevents other people accidentally using an outdated API introduced in an alpha release...

-- JeroenVanGelderen

For versioning, I would stick with DD-MMM-YYYY or 16-DEC-1997. This makes the day and the month and the year easily identifiable so that we don't get into the debate about having month or day first... Although, Jeroen's method allows for the versions to be sorted easily in a file system.

- ClarkEvans

This is going to sound slightly ridiculous, but what if we have 2 versions of a class file from the same day? Overall, I like Jeroen's idea (used it myself without the dots for 8.3 file names in Windows). But I have run into the problem frequently with my development team. This isn't so much an issue for releases, it's an issue for development. Most version control systems generate version numbers when code is checked in. Maybe we'd be further along just letting the tool handle it.

These are more musings than opinions, though. --BillRehm

Well, my idea is that version tracking will become easier this way. You cannot forget where exactly you are. Files are sorted neatly in the filesystem or more generally sorting is easier than with the 22-DEC-1997 approach.

As for the order of mm and dd: when you start with a year there's only a single accepted notation: jjjj-mm-dd. jjjj-dd-mm is unknown...

The vc system might be a problem but we do not use one here and if we did, we should adapt it... It's important to use a uniform versioning standard on JOS so we cannot just have the vc system handle versioning...

However, most vc systems can include a date in the file so with a little code we could use the included date string and convert it to version number... Most important point here is that you would only use 'my' versioning on releases, not for internal development builds...

As for the more versions on one day thing: don't do it or take a day ahead...

-- JeroenVanGelderen

If we all use the version control system, wouldn't that sort of make it the uniform versioning standard?

RE: more versions on one day. I guess you're just addressing the special case where we are doing releases, not the general one where we have multiple versions of source files. Remember: the JOS group is spread across both international date lines. At the very least, we need to set all version times to GMT, which is equally a pain in the ass, when a version control system like CVS can take care of this for us.

Maybe we're talking about apples and oranges, Jeroen. If we are, feel free to delete this comment and I'll start translating your "versions" into "release numbers" and worry about version control when we have some version we need to control. --BillRehm

Back to CodingConventionsTasks



Content of these pages are owned and copyrighted by the poster.
Hosted by: