Yep.

http://sourceforge.net/projects/open-cobol/

Next will be putting up the tree for SVN, and then perhaps a version patched to fix void C function calls and CALL RETURNING NULL.

Cheers,
Brian

Finally (with a delay of three years) there is a 1.1 at SF. This is good, but I'm unsure if the packages will be build on a pre-release version. How is the effort of getting it named as release version (maybe after your patches)?
For patching: Please keep in mind that there are a lot of other fixes (most with small code changes) for 1.1 feb09 that we can (should) include.

Is there any release plan for the community edition? Would it be useful to add me (with svn access) to the project?

human

BTW: I wonder that I did not recognized bgiroud as a member (in this case even project manager) at the SF project.

Yeah, in my humble opinion Feb 2009 is ready for distro rollouts, except for a few doc strings regarding version number in some of the older headers, so stickler distributions may well reject and request changes. And yes a community edition could do that nicely. I'll try and squeeze time in to get the repos opened this weekend. I've looked and there should not be many lintian failures.

I'm going to try and get my head around the existent CVS repo, (the SourceForge shell has command line access by default ... SourceForge is pretty cool ...) and try and squirrel a pristine Feb 2009 to that tree, umm without unduly inconveniencing distro package builders that expect to find 1.0 by default.

58 downloads on the first day. There is 88,000 and counting for the 1.0 tar ball.

=============
And might as well use this thread for permission requests.

sf-mensch is in (with "little pink spam bot fighter" powers).

When fighting spam bots I find it worthwhile youtubing Yoshimi battles the Pink Robots by the Flaming Lips; played over and over again until the cleanup of the evil natured robots is complete.

Cheers,
Brian

Revision 1 of OpenCOBOL-1.1pre-rel checked in to SVN at



Access requests can go in this thread, or at http://forum.peoplecards.ca for those still denied opencobol.org registrations (which may get lost in noise from robots, sorry in advance), and the first and last resort will be the open-cobol mailing list, which has always been hosted out of the SourceForge project.

human; If you could, please test with your svn --username.

Anyone reading along; I'm informally assuming a leadership role in the OpenCOBOL 1.1 Community Edition, until I get told to stop. I do this as a fan, not a professional, and you may have noticed that I like to clown around. Perhaps too much clowning for the current level of quality of the software.

This is not a fork I foresee as long lived. Other sources will supersede the tweaks posted to this tree, but in the mean-while...

Criticize at will, please.

Cheers,
Brian

Even if this may not live long, I highly vote for using "standard" SVN repo structure (trunk/tags/branches). If you're OK with that I'll change the repo structure.

Other stuff (patches) I'd like to commit:
- some of my patches for other compilers (most WIN) (included by Roger into 2.0)
- patch to screenio.c for better key/WIN support and changed cob_bell (including a new FUNCTION for belling the user) (included by Roger into 2.0)
- patch for some BDB stuff (included by Roger into 2.0)
- slightly changed patch from mrcool [maybe it's better if he commits it?]
- patch for EXIT PROGRAM RETURNING (NOT accepted/included by Roger into 2.0, as far as I know)

human

human; I'm ok with a repo structure update.

And then we should branch I guess and let some patches in.

Have fun, and go ahead.

Cheers,
Brian

Structure (and svn-ignore) done, tag for 1.1pre-rel set. Now I'd submit patches into trunk (trying to submit one by one).

What about patches from others? Should they be added to SF project (to get svn rights) and commit their patches themselves?
What about the void patch you wrote about?

human

BTW: As the newcob.val is broken at sim-basis.de and the official site is faster, you may want to change tests/cobol85/README

I'm going to make an announcement post human, but I'd like to ask you to screen any commits and hold the master keys to the SVN repo.

Cheers,
Brian

> - slightly changed patch from mrcool [maybe it's better if he commits it?]

I'll be happy to commit my screenio changes.

In one shop I worked in, the developers put labels on all of the files that they checked in. (This was pvcs). The labels were the release numbers. We could check in changes by version. A check in might go to 1.0, 1.1, or 2.0 by the label. We could also move labels up and down the file list if needed.

We could check out by release number labels. It was nice to be able to check out a 1.0, 1.1, or 2.0 version and duplicate an issue.

In OpenCobol, does the developer do this? Or do tags get assigned to the tips whenever a release is declared complete?

Is there a document that describes what needs to happen to commit changes? At a minimum there should be some text describing what changed as a part of the commit. Do we assign labels or tags at commit time? Is there anything else the developer should do?

When I get set up on Source Forge I'll start looking into making the screenio.c and screenio.cpy commit.

I'd also like to svn update any other patches from screenio.c, and test them, before I commit. It they were committed first that would be good. Otherwise, someone else will have to do the testing.

I'll post most patches to screenio.c (not yours) when I get the necessary information from btiffin concerning copyrights (I suggest that anyone posting at the svn passes them to Roger While) and how to handle stuff that was included (maybe even programmed) by Roger for OpenCOBOL 2.0.

I don't think there is a need to label/tag any not released version (if not for branching) - you can get any version from the history. Here are my key points how to commit:
- A good description as svn commit message
- A short description in the Changelogs (you'll find them on the file system) [with the original date of the first public publishing]

@Brian: You have a PM in this board, just in case you did not recognize it.

human