What about new version of OW?

[Igor V. Krasikov]

Hi!

Does it make sense to expect a new official version of the Open Watcom
or project is de facto stopped? And it's better to migrate to different
C++ compiler?

What is the expected date of a new release?

I.K.

[Marty Stanquist]

Development has not stopped, but I'm not able to commit to a release
schedule at this time. What specific C++ issues are you having?

Marty

"Igor V. Krasikov" wrote in message news:l28k92$mve$***@www.openwatcom.org...

Hi!

Does it make sense to expect a new official version of the Open Watcom
or project is de facto stopped? And it's better to migrate to different
C++ compiler?

What is the expected date of a new release?

I.K.

[Igor V. Krasikov]

Post by Marty Stanquist
Development has not stopped, but I'm not able to commit to a release
schedule at this time. What specific C++ issues are you having?

Thank you!

It was a global question :)

More specifically, I am missing some of the standard features of
templates and STL. Of course, there are workarounds, but it would be
better to have more straightforward solutions.

I.K.

[Marty Stanquist]

I agree, templates and the STL are incomplete. This is a top priority for
the C++ compiler.

Marty

Post by Marty Stanquist
Development has not stopped, but I'm not able to commit to a release
schedule at this time. What specific C++ issues are you having?

Thank you!

It was a global question :)

More specifically, I am missing some of the standard features of
templates and STL. Of course, there are workarounds, but it would be
better to have more straightforward solutions.

I.K.

[Igor V. Krasikov]

Post by Marty Stanquist
I agree, templates and the STL are incomplete. This is a top priority
for the C++ compiler.

A propos, is C++11 support planned in new version?

I.K.

[Marty Stanquist]

Post by Marty Stanquist
I agree, templates and the STL are incomplete. This is a top priority
for the C++ compiler.

A propos, is C++11 support planned in new version?

I.K.

Yes, I'm looking at that now.

Marty

[Igor V. Krasikov]

Post by Igor V. Krasikov
A propos, is C++11 support planned in new version?
I.K.
Yes, I'm looking at that now.
Marty

Thanks, it would be great!

[Lynn McGuire]

Post by Igor V. Krasikov

Post by Marty Stanquist
I agree, templates and the STL are incomplete. This is a top priority
for the C++ compiler.

A propos, is C++11 support planned in new version?
I.K.
Yes, I'm looking at that now.
Marty

Would it not be better to get version 2.0
out the door? Not that I could do it, I am
getting more and more incompetent by the day.

Lynn

[Marty Stanquist]

Post by Igor V. Krasikov

Post by Marty Stanquist
I agree, templates and the STL are incomplete. This is a top priority
for the C++ compiler.

A propos, is C++11 support planned in new version?
I.K.
Yes, I'm looking at that now.
Marty

Would it not be better to get version 2.0
out the door? Not that I could do it, I am
getting more and more incompetent by the day.

Lynn

Version 2.0 is going to be a major upgrade for the languages, GUI, host
platforms, targets, tools, and libraries. It's a lot of work. What did you
have in mind for the short term?

Marty

[Paul S. Person]

On Wed, 9 Oct 2013 01:26:58 -0500, "Marty Stanquist"

Post by Marty Stanquist

Post by Lynn McGuire
Would it not be better to get version 2.0
out the door? Not that I could do it, I am
getting more and more incompetent by the day.

Version 2.0 is going to be a major upgrade for the languages, GUI, host
platforms, targets, tools, and libraries. It's a lot of work. What did you
have in mind for the short term?

If we need to get a new one out, why not just call it "1.10" and be
done with it? At least we wouldn't get people wondering if the project
is dead ...

This, of course, only applies if doing a new minor-version release
would otherwise make sense. And if going from 1.9 to 1.10 wouldn't
break anything.

To put it another way: reserving "2.0" for a major upgrade is all very
well, but that shouldn't become an excuse for not doing
otherwise-appropriate releases in the meantime.

[Marty Stanquist]

"Paul S. Person" wrote in message news:***@4ax.com...

On Wed, 9 Oct 2013 01:26:58 -0500, "Marty Stanquist"

Post by Marty Stanquist

Post by Lynn McGuire
Would it not be better to get version 2.0
out the door? Not that I could do it, I am
getting more and more incompetent by the day.

Version 2.0 is going to be a major upgrade for the languages, GUI, host
platforms, targets, tools, and libraries. It's a lot of work. What did you
have in mind for the short term?

If we need to get a new one out, why not just call it "1.10" and be
done with it? At least we wouldn't get people wondering if the project
is dead ...

This, of course, only applies if doing a new minor-version release
would otherwise make sense. And if going from 1.9 to 1.10 wouldn't
break anything.

To put it another way: reserving "2.0" for a major upgrade is all very
well, but that shouldn't become an excuse for not doing
otherwise-appropriate releases in the meantime.
--
"Nature must be explained in
her own terms through
the experience of our senses."


I'd say yes to all three:

* Release 2.0 will be a major upgrade.
* Intermediate release 1.10 is appropriate.
* And sure, we're bound to break something.

I'll try to complete work on a test Perforce server ( using one of my test
machines) with the latest Perforce server release. Hopefully, this will tell
us how difficult revision 1.10 will be.

Marty

[Paul S. Person]

On Wed, 9 Oct 2013 15:37:39 -0500, "Marty Stanquist"

Post by Paul S. Person
On Wed, 9 Oct 2013 01:26:58 -0500, "Marty Stanquist"

Post by Marty Stanquist

Post by Lynn McGuire
Would it not be better to get version 2.0
out the door? Not that I could do it, I am
getting more and more incompetent by the day.

Version 2.0 is going to be a major upgrade for the languages, GUI, host
platforms, targets, tools, and libraries. It's a lot of work. What did you
have in mind for the short term?

If we need to get a new one out, why not just call it "1.10" and be
done with it? At least we wouldn't get people wondering if the project
is dead ...
This, of course, only applies if doing a new minor-version release
would otherwise make sense. And if going from 1.9 to 1.10 wouldn't
break anything.
To put it another way: reserving "2.0" for a major upgrade is all very
well, but that shouldn't become an excuse for not doing
otherwise-appropriate releases in the meantime.

I'm leaving the above as-is; from my understanding of the matter, you
aren't quoting properly: the stuff you quote needs a level indicator,
and, by including the entire post, you included my sig, which caused

Post by Paul S. Person
* Release 2.0 will be a major upgrade.
* Intermediate release 1.10 is appropriate.
* And sure, we're bound to break something.
I'll try to complete work on a test Perforce server ( using one of my test
machines) with the latest Perforce server release. Hopefully, this will tell
us how difficult revision 1.10 will be.

which is all very irritating.

But enough griping.

My point was that some tests may be for an OW version greater than,
say, "1.3", and might fail if they only check the first decimal digit,
since "1.10" would be treated as "1.1", which is less than "1.3",
although release 1.10 almost certainly would work properly if release
1.9 did.

And I thought there was a well-known (well, to those who have done it
before, anyway) procedure for producing a new release.

[Marty Stanquist]

"Paul S. Person" wrote in message news:***@4ax.com...

On Wed, 9 Oct 2013 15:37:39 -0500, "Marty Stanquist"

Post by Paul S. Person
On Wed, 9 Oct 2013 01:26:58 -0500, "Marty Stanquist"

Post by Marty Stanquist

Post by Lynn McGuire
Would it not be better to get version 2.0
out the door? Not that I could do it, I am
getting more and more incompetent by the day.

Version 2.0 is going to be a major upgrade for the languages, GUI, host
platforms, targets, tools, and libraries. It's a lot of work. What did you
have in mind for the short term?

If we need to get a new one out, why not just call it "1.10" and be
done with it? At least we wouldn't get people wondering if the project
is dead ...
This, of course, only applies if doing a new minor-version release
would otherwise make sense. And if going from 1.9 to 1.10 wouldn't
break anything.
To put it another way: reserving "2.0" for a major upgrade is all very
well, but that shouldn't become an excuse for not doing
otherwise-appropriate releases in the meantime.

I'm leaving the above as-is; from my understanding of the matter, you
aren't quoting properly: the stuff you quote needs a level indicator,
and, by including the entire post, you included my sig, which caused

Post by Paul S. Person
* Release 2.0 will be a major upgrade.
* Intermediate release 1.10 is appropriate.
* And sure, we're bound to break something.
I'll try to complete work on a test Perforce server ( using one of my test
machines) with the latest Perforce server release. Hopefully, this will tell
us how difficult revision 1.10 will be.

which is all very irritating.

But enough griping.

My point was that some tests may be for an OW version greater than,
say, "1.3", and might fail if they only check the first decimal digit,
since "1.10" would be treated as "1.1", which is less than "1.3",
although release 1.10 almost certainly would work properly if release
1.9 did.

And I thought there was a well-known (well, to those who have done it
before, anyway) procedure for producing a new release.
--
"Nature must be explained in
her own terms through
the experience of our senses."

I know, it's a hurdle. I have the procedure and it requires P4V, and thus a
server upgrade. I'm trying to dry run the upgrade and build on a test
machine to see what will break. I'm hoping that any problems will be minor.
We'll see.

Marty

[Paul S. Person]

On Thu, 10 Oct 2013 14:13:02 -0500, "Marty Stanquist"

Post by Marty Stanquist
I know, it's a hurdle. I have the procedure and it requires P4V, and thus a
server upgrade. I'm trying to dry run the upgrade and build on a test
machine to see what will break. I'm hoping that any problems will be minor.
We'll see.

OK, that makes sense.

[r***@hotmail.com]

On Fri, 11 Oct 2013 20:57:16 -0300, Paul S. Person

Post by Paul S. Person
On Thu, 10 Oct 2013 14:13:02 -0500, "Marty Stanquist"

Post by Marty Stanquist
I know, it's a hurdle. I have the procedure and it requires P4V, and thus a
server upgrade. I'm trying to dry run the upgrade and build on a test
machine to see what will break. I'm hoping that any problems will be minor.
We'll see.

OK, that makes sense.

As far as I can remember, a version number of 1.10 is bound to break
something.
The Watcom way is to use 1.9a, 1.9b and so on in this case.
It may not be sexy, but that is what the tool chain is expecting, and
consistent
with earlier versions.

Roald

[Hans-Bernhard Bröker]

Post by r***@hotmail.com
On Fri, 11 Oct 2013 20:57:16 -0300, Paul S. Person
As far as I can remember, a version number of 1.10 is bound to break
something.

Well, for starters it breaks the version identification scheme in the
predefined __WATCOMC__ macro. That computes as

100 * major version + 10 * minor version + patchlevel

where major_version is 12 for OW 1 (continuing from the last commercial
version 11), minor_version is currently 9, and patchlevel is 0 for
"nothing", 1 for "a", 2 for "b" etc. So the current version is 1290.

Under this scheme OW 2.0 and 1.10 would both be 1300. No good.

So if there's to be another 1.something release before 2.0, it has to be
1.9a.

[Lynn McGuire]

Post by Hans-Bernhard Bröker

Post by r***@hotmail.com
On Fri, 11 Oct 2013 20:57:16 -0300, Paul S. Person
As far as I can remember, a version number of 1.10 is bound to break
something.

Well, for starters it breaks the version identification scheme in the
predefined __WATCOMC__ macro. That computes as
100 * major version + 10 * minor version + patchlevel
where major_version is 12 for OW 1 (continuing from the last commercial
version 11), minor_version is currently 9, and patchlevel is 0 for
"nothing", 1 for "a", 2 for "b" etc. So the current version is 1290.
Under this scheme OW 2.0 and 1.10 would both be 1300. No good.
So if there's to be another 1.something release before 2.0, it has to be
1.9a.

If 2.0 is hard to produce for some reason then
1.9A or 1.91 would be good. I seem to remember
that the RDOS code may need an intermediate
version of the compiler or something like that.

Lynn

[Paul S. Person]

Post by Lynn McGuire

Post by Hans-Bernhard Bröker

Post by r***@hotmail.com
On Fri, 11 Oct 2013 20:57:16 -0300, Paul S. Person
As far as I can remember, a version number of 1.10 is bound to break
something.

Well, for starters it breaks the version identification scheme in the
predefined __WATCOMC__ macro. That computes as
100 * major version + 10 * minor version + patchlevel
where major_version is 12 for OW 1 (continuing from the last commercial
version 11), minor_version is currently 9, and patchlevel is 0 for
"nothing", 1 for "a", 2 for "b" etc. So the current version is 1290.
Under this scheme OW 2.0 and 1.10 would both be 1300. No good.
So if there's to be another 1.something release before 2.0, it has to be
1.9a.

If 2.0 is hard to produce for some reason then
1.9A or 1.91 would be good. I seem to remember
that the RDOS code may need an intermediate
version of the compiler or something like that.

As I understand, the only problem with producing 2.0, as opposed to
1.9a, is that "2.0" is being reserved for the Next Big Leap, whenever
that occurs.

Apparently, producing any new release will require upgrading the
Perforce server so that P4V can be used with it. Which, IIRC from the
last time I looked at the procedure online, is not a trivial task.

[Marty Stanquist]

Post by Lynn McGuire

Post by Hans-Bernhard Bröker

Post by r***@hotmail.com
On Fri, 11 Oct 2013 20:57:16 -0300, Paul S. Person
As far as I can remember, a version number of 1.10 is bound to break
something.

Well, for starters it breaks the version identification scheme in the
predefined __WATCOMC__ macro. That computes as
100 * major version + 10 * minor version + patchlevel
where major_version is 12 for OW 1 (continuing from the last commercial
version 11), minor_version is currently 9, and patchlevel is 0 for
"nothing", 1 for "a", 2 for "b" etc. So the current version is 1290.
Under this scheme OW 2.0 and 1.10 would both be 1300. No good.
So if there's to be another 1.something release before 2.0, it has to be
1.9a.

If 2.0 is hard to produce for some reason then
1.9A or 1.91 would be good. I seem to remember
that the RDOS code may need an intermediate
version of the compiler or something like that.

As I understand, the only problem with producing 2.0, as opposed to
1.9a, is that "2.0" is being reserved for the Next Big Leap, whenever
that occurs.

Apparently, producing any new release will require upgrading the
Perforce server so that P4V can be used with it. Which, IIRC from the
last time I looked at the procedure online, is not a trivial task.
--
"Nature must be explained in
her own terms through
the experience of our senses."

The next intermediate release is set to include C compiler fixes for RDOS
and various fixes for Windows 7 hosts. The numbering scheme 1.91 or 1.90a
sounds good to me.

Marty