Puplishing of the next release candidate ?

[Ivan Denisov]

How do you see the work on this?

I suggest to publish OberonCore version as a First Stable after some discussions here.

Your ideas?

[Ivan Denisov]

Let's make public repository in GitHub or Bitbucket?

I can apply the changes from OberonCore Stable version one by one with comments in English.

[ReneK]

Again: What for do we neet github right now?

The community as a whole does not produce tons of differing versions, and right now, this would be the wrong signal. Right now, just as OMI did in the past, we need ONE version. No need for versioning tools right now.

Also, I think I want to discuss why OberonCore thinks that a "stable version" is against the mindset of Oberon. This could be about a language issue, or a concept issue, nevertheless, we should be clear on this one, before producing something even us 10 center members could not fully support.

[Ivan Denisov]

Again: What for do we neet github right now?

The community as a whole does not produce tons of differing versions, and right now, this would be the wrong signal. Right now, just as OMI did in the past, we need ONE version. No need for versioning tools right now.

I have started new discussion here. Let's members share their thoughts about repository.

Also, I think I want to discuss why OberonCore thinks that a "stable version" is against the mindset of Oberon. This could be about a language issue, or a concept issue, nevertheless, we should be clear on this one, before producing something even us 10 center members could not fully support.

Let's call this "stable version" — "next release candidate"?

[ReneK]

I don't know. Let's have OberonCore tell us, why they object to the term, and what this is all about. Let's not jump to solutions that really don't explain anything. Let's try to understand first.

[Josef Templ]

Again: What for do we neet github right now?

The community as a whole does not produce tons of differing versions, and right now, this would be the wrong signal. Right now, just as OMI did in the past, we need ONE version. No need for versioning tools right now.

The primary task of a source code management tool such as git in my oppinion is not to
maintain the competing variants of BB but to keep track of the ONE and only version,
which now happens to be in the public domain.
The versioning tool maintains the history and coordinates the development steps of this ONE version.
A source code repository is at the core of any open source project.
There can be any number of private forks but this would be counterproductive for the BB project.
Therefore, in my oppinion, we need a versioning tool better sooner than later.
The starting point of such a repository would be the latest OMI distribution 1.6rc6, of course.
Any change, be it from oberoncore or from somebody else, needs to be carefully discussed and reviewed
before it gets into it.

To me it is not an option to stick with the oberoncore repository because of the language barrier.
The BB project should continue to be an international project and as such the communication language is English,
as it used to be in the past while it was maintained by OMI.
Google Translate is not an approriate tool for overcoming the language barrier.

- Josef

[cfbsoftware]

The starting point of such a repository would be the latest OMI distribution 1.6rc6, of course.

The release candidate is no more. As of today it is the final release of BlackBox 1.6. You can download it via the following link:

http://www.oberon.ch/zip/SetupBlackBox16.exe

[Ivan Denisov]

That very good news. However we need to analyze OpenPoints and patches and then think about next release and the way of developing it.

We have also compiled a collection of open points and patches that did not make it into 1.6. You can get them at the following URLs:

http://www.oberon.ch/zip/OpenPoints.txt

Patches by Koen Desaeger:
http://www.oberon.ch/zip/PatchesByKoenDesaeger.txt

Patches by Helmut Zinn:
http://www.zinnamturm.eu/pac/B201310070816.zip