Converters (merged with Converters Docu)

[Ivan Denisov]

1.7.1 can has only bugfixes, no features.

Not even 1.8 but also 1.7 for Linux/BSD should be discussed and started.

I think, that further we can distribute some work. You can concentrate on handling found bug fixes for 1.7.1. At the same time another members can think about neccessary features for 1.8 and avaluate them in test builds.

I am defenitly will concentrate my efforts around 64-bit version and the version for Linux/BSD.

[Josef Templ]

1.7.1 can has only bugfixes, no features.

Why not?
The principle behind the numbering is that the first number is the software compatibility level.
As longs as a simple recompilation suffices, at least for the vast majority of cases, it is 1.
If the forms subsystem or the text subsystem or other core parts of the library change significantly,
it would be 2.
The second number is the binary compatibility number.
as long as there is no (or almost no?) binary incompatibility it will be 7.
If a new command is added, for example, this does not affect the binary compatibility and it is still 7.
1.8 marks a (significantly) binary incompatible new version. This means you have to recompile
all your sources in order to upgrade.
This was, to my knowledge, always the idea behind the version numbers from ominc
and it worked quite well until 1.6, so why should that be changed now?

Not even 1.8 but also 1.7 for Linux/BSD should be discussed and started.

I think, that further we can distribute some work. You can concentrate on handling found bug fixes for 1.7.1. At the same time another members can think about neccessary features for 1.8 and avaluate them in test builds.

I am defenitly will concentrate my efforts around 64-bit version and the version for Linux/BSD.

Big projects such as a native version for Linux or a 64 bit version cannot be handled
inside the center with the current development process and resources.
This must be done offline, i.e. outside the center.

- Josef

[Ivan Denisov]

1.7.1 can has only bugfixes, no features.

Why not?
The principle behind the numbering is that the first number is the software compatibility level.
As longs as a simple recompilation suffices, at least for the vast majority of cases, it is 1.
If the forms subsystem or the text subsystem or other core parts of the library change significantly,
it would be 2.
The second number is the binary compatibility number.
as long as there is no (or almost no?) binary incompatibility it will be 7.
If a new command is added, for example, this does not affect the binary compatibility and it is still 7.
1.8 marks a (significantly) binary incompatible new version. This means you have to recompile
all your sources in order to upgrade.
This was, to my knowledge, always the idea behind the version numbers from ominc
and it worked quite well until 1.6, so why should that be changed now?

You right. If the feature is really required and binary compatible with 1.7 it can come to patch.
However features, what will have binary incomparability can be done as the additional components
I think, that important feature, that can be added in 1.7.1 is an package manager for easy install/upgrade/remove components.

Big projects such as a native version for Linux or a 64 bit version cannot be handled
inside the center with the current development process and resources.
This must be done offline, i.e. outside the center.

I do not agree, because during the creation of the Center we decided to support another OS.
http://wiki.blackboxframework.org/index ... e_software
Current process and resources are such because we have nothing interesting to do.
If we will make more value, we also will have more people and more resources.

[Josef Templ]

I always pointed out that 64 bit is a lot of work and not on my TODO list
as long as there is the Win32 API available.

If somebody wants to do it, fine, but:
Warning: It will need at least half a person year of concentrated work, probably more.
This is not trivial and you cannot do this in the usual issue/voting style.
It is a separate project that starts as a private project of one or several people.
The center cannot do much to help until it is finished, I am afraid.
Most center members are unable to get git running on their PCs, so how
should they be able to support the 64 bit project?
When it is finished, we can offer the web hosting, for example.

Good luck, anyway.

- Josef

[Josef Templ]

How shall we proceed with the open Converters discussion,
I mean, the export of the next field?

If it is not in 1.7 it will not be there for a long time.

- Josef

[Robert]

How shall we proceed with the open Converters discussion,
I mean, the export of the next field?

I would vote to support just changing '-' to '*' in 1.7.

If this is found to be inadequate, and a more involved solution is needed, it can be added in 1.8 when we have experience with the problems with this simple solution.

[DGDanforth]

See App Center Store

Installing CacketRtfConv places it at the end of the list of converters. I was going to say that it didn't work until I realized I had
selected the wrong converter (the standard rtf converter) when I tried it. I needed to scroll way down to the end of the
converter list to see the (Cachet) Rtf converter.

What I would prefer is to "replace" the Standard rtf converter with the Casket rtf converter. Making Converters.list modifiable
would make that possible. So there is another reason for

Code: Select all

	TYPE
		Converter = POINTER TO RECORD 
			next*: Converter;
			imp-, exp-: Dialog.String;
			storeType-: Stores.TypeName;
			fileType-: Files.Type;
			opts-: SET
		END;

[DGDanforth]

We forgot to change the documentation for Converters so I just did that.
I did a clone, modified docu, a commit, and a push. Worked.

Now I have forgotten whether it is necessary to do a second pull request for issue-#122.
Is it?
-Doug

[Ivan Denisov]

We forgot to change the documentation for Converters so I just did that.
I did a clone, modified docu, a commit, and a push. Worked.

Now I have forgotten whether it is necessary to do a second pull request for issue-#122.
Is it?

Seems to be ok:
http://redmine.blackboxframework.org/pr ... 56fd0937c7
Thank you, Doug, that you mentioned this.

[DGDanforth]

I just did a "replace" in the Converters.list of 'rtf' with Casket's version. It worked and I preserved
the rest of the list. Thank's guys!