44 replies to this topic

[paraglider]

On every build uploaded to http://winbuilder.net/download.php please use a unique internal version number ( visible from the file properties in explorer ).

The most significant part of the version number should always be the same as the major version number so version 80 should be 80.X.Y.Z

Z should be incremented for silent updates. So you would have so far:

80.0.0.0 - first version 80 public release
80.0.0.1 - first silent update
80.0.0.2 - second silent update

Y should be incremented for bug fix builds prior to a SP.

X should be the SP number so 80 SP1 will be 80.1.0.0

Silent update to SP1 would be 80.1.0.1

If no SP builds then 81.0.0.0 would be the next major public build.

[Galapo]

Been some discussion here: http://www.boot-land...showtopic=10565

Would seem that part of the idea has been rejected, ie X and Y are redundant given that there won't be any service pack and bug fixes released only major version releases.

Regards,
Galapo.

[Wonko the Sane]

Been some discussion here: http://www.boot-land...showtopic=10565

Would seem that part of the idea has been rejected, ie X and Y are redundant given that there won't be any service pack and bug fixes released only major version releases.

Regards,
Galapo.

The given link resolves to "a suffusion of yellow".

Since I don't think that a bunch of dots and numbers cost that much, and knowing that:

there won't be any service pack and bug fixes released only major version

is simply a declaration of intent that will soon be overtaken by contingencies/emergencies, I stand for the W.X.Y.Z where:
W=Major Wersion
X=SP version
Y=Bug fix pre-SP
Z=Silent Update level

Though of course the whole idea of a "silent update" is pure folly, as I see it.

Each time a given number is increased by one all "lower parts" should be reset to 0.

Example:
80.0.0.1
80.0.0.2
80.0.1.0
80.1.0.0

And we can also feed these numbers to a WHOIS service :
http://whois.domaintools.com/80.0.0.2

As soon as we get here:
http://whois.domaintools.com/127.0.0.0
we'll have a good, stable release.





Wonko

[Galapo]

The given link resolves to "a suffusion of yellow".

At the link given (for those with access) Nuno explains that no bugfix (and presumably service pack releases too) releases will be released. Once a bug has been identified, then WB progresses to a new alpha, not a bugfix to the current stable/major release. While means that from now on we'll only ever see releases like these: 082.0.0.0, 084.0.0.0.

Regards,
Galapo.

[Wonko the Sane]

At the link given (for those with access) Nuno explains that no bugfix (and presumably service pack releases too) releases will be released.

I like the new approach , since we need more partecipation by "common users", we put the explanations in a "reserved to developers only" area.

But we link to them in the "open to all" area, this way we manage to convey how everything is public and transparent and open to suggestions.

So, common users are allowed to make suggestions and wishes, but these items will be discussed (and approved or rejected) in the private rooms of the developers.

Once a bug has been identified, then WB progresses to a new alpha, not a bugfix to the current stable/major release. While means that from now on we'll only ever see releases like these: 082.0.0.0, 084.0.0.0.

Will we have even and odd releases or not?




Wonko

[Galapo]

I like the new approach , since we need more partecipation by "common users", we put the explanations in a "reserved to developers only" area.

Nuno cropped posts out of another topic and placed them in the reserved area. If he thinks the issue is open for public discussion, he'll move them again I guess.

Will we have even and odd releases or not?

Odd releases will have the odd numbering I assume, and I also assume will have incrementation, say 081.X.Y.Z. Once an even-numbered stable is released, say the next 082, Nuno's idea is that there will be no fixes permitted. If any are needed, then we roll on to 083.X.Y.Z.

To give you a taste of what was said at the reserved link, I wrote:

I fail to see why there cannot be minor updates to a stable release. Most other software I know releases updates to stable releases, whether this be bug fixes and sometimes a few additional features. Later there might be another stable version (ie, major version) released incorporating these fixes and features alongside other further development.

I hate it when paid software does exactly this, not fixing bugs with the stable/major release and you can only get a fix with paying for the next stable/major release.

Lucky for me WB is freeware, so it's not a big concern. Just that I think individual projects should be able to expect fixes to a stable and not have to make use of alphas if needing the particular fix.

Needless to say, we had to agree to disagree.

So I guess paraglider's suggestion will be mostly relevant to non-stable releases, ie alpha and beta versions etc.

Regards,
Galapo.

[Wonko the Sane]

Thanks.



Wonko

[Brito]

Needless to say, we had to agree to disagree.

I don't disagree with the internal file version. I just don't think that it is appropriate to release bug fixes that may introduce additional bugs and make these binaries available to the public without doing proper testing and letting every other project developers know what has changed.

Since we can't do a new release for every bug that is fixed, we fix and use the alpha to properly test all bug fixes or new features before a stable can be made available to public.

Last time a stable was released, 7 months had passed. We are aiming at half this time interval and everyone at the same time will be capable of testing and have time for preparing their projects for the newer version.

Internal file versioning is a good idea to keep up with changes regardless of whatever winbuilder.exe you're using.

----------------------------------------------

I might as well include my previous reply.

So this bug fix release should be called 80.0.0.4 or similar.

Ok, as long as it is only seen inside the file properties.

I think the fix hardly constitues a new WB alpha release. Isn't it just a minor fix to a stable release?

Minor fixes will be added to alphas.

We keep the stable untouched otherwise it won't be stable anymore.

When enough bugs are corrected, we proceed with a thorough testing until a new stable is ready.

---------------

[Galapo]

Since we can't do a new release for every bug that is fixed, we fix and use the alpha to properly test all bug fixes or new features before a stable can be made available to public.

Ni Nuno,

I find this to be a contradiction in terms -- calling a stable a stable if there is remaining known bugs. It is then only a stable in name only. To fit with the way you'd like to issue WB releases, I suggest you call your stables "major" releases. This way you get away from ideas like mine where I can't consider a stable a stable until it is stable. Instead, you'd just have "major releases" and if any bugs are found, then users can obtain the fix at the next "major release".

Regards,
Galapo.

[Brito]

Stable/Unstable versions adopt this definition:

In open source programming, version numbers or the terms stable and unstable commonly distinguish the stage of development.

The term stable refers to a version of software that is substantially identical to a version that has been through enough real-world testing to reasonably assume there are no significant problems, or at least that any problems are known and documented.

On the other hand, the term unstable does not necessarily mean that there are problems—rather, that enhancements or changes have been made to the software that have not undergone thorough testing and that more changes are expected to be imminent.

Users of such software are advised to use the stable version if it meets their needs, and to only use the unstable version if the new functionality is of interest that exceeds the risk that something might simply not work right.

http://en.wikipedia....ble_or_unstable

----------------

Winbuilder.exe will be following a release life cycle in a very similar to what is described on the previous link.

[Galapo]

Reading the above, it seems ironic to me that LiveXP for one constantly seems to only support versions which are not the stable releases. That's fine, because this is certainly true:

Users of such software are advised to use the stable version if it meets their needs, and to only use the unstable version if the new functionality is of interest that exceeds the risk that something might simply not work right

Currently can't seem to get LiveXP updated due to variable/macro issues, example given here: http://www.boot-land...showtopic=10567

Regards,
Galapo.

[Wonko the Sane]

The essential point that seems to me not so evident, and that was completely ignored up to current release - let's hope it won't be so in the future - is that the "new stable" should be always "latest unstable" renamed, after a reasonable time of NO "critical" bugs found, and "promoted" to stable, WITHOUT ANY modification whatsoever if not the name and version change.

The recent havoc it was caused because a number of things were changed between "latest unstable" and "new stable".

I will once again quote myself:
http://www.boot-land...?...=6956&st=74
http://www.boot-land...?...=8980&st=35

just for the sake of being able to say "See, I had told you!" , but I am not still convinced that the at the time suggested approach (or a similar one) will be used, so I will have to use a direct question:
Nuno, is the new development model fully compliant to the above described IMNSHO essential point or not?



Wonko

[Brito]

The essential point that seems to me not so evident, and that was completely ignored up to current release - let's hope it won't be so in the future - is that the "new stable" should be always "latest unstable" renamed, after a reasonable time of NO "critical" bugs found, and "promoted" to stable, WITHOUT ANY modification whatsoever if not the name and version change.

Yes, this is what is aimed. An RC is launched to public with some good time in advance to allow all projects developers to adapt their projects to the new binary and only after this adaptation period comes the stable without any change.

If bugs are still found on either RC or stable, they're identified and marked to be addressed on the next cycle, no more last minute fixes. Each cycle shouldn't last more than 3~4 months to avoid long gaps and disruptions on features between stables.

The only software that I've found so far without bugs is nada 0.5:
http://www.bernardbe.../click.php?id=2

[Wonko the Sane]

The actual link is this one:
http://www.bernardbe.../NaDa/index.php

And of course you are wrong, the old version, NaDa 0.9, was far better , they messed it up when they made it portable on Windows systems.



Wonko

[pscEx]

Currently can't seem to get LiveXP updated due to variable/macro issues, example given here: http://www.boot-land...showtopic=10567
Galapo.

It does not work whis wrong script syntax statements.

In the mentioned post I showd you the correct script command use which lets it work.

BTW: By the Developers RC2 was never declared as stable. It was one of several publications on the way to a released problem.
If somebody for a stable project uses a new functionality which on the way to the final release disappears, there is no reason to declare the final release as "Not stable".

Peter

[Wonko the Sane]

Peter,
this time I am serious.

I do understand the complexity of Winbuilder, but when there is a profound change to the Syntax the engine understands, it should be "advertised" with some advance.

The practical result is that we have right now a "better" engine, but no correct fuel to feed it with.

The new car may go faster, but right now it cannot even start, the "old" one at least was able to run, maybe with some hiccups, but actually worked.

And now, back to the usual funny mood, just as for Nuno, I can say "See, I told you." :
http://www.boot-land...?...=8980&st=35



Wonko

[Brito]

And now, back to the usual funny mood, just as for Nuno, I can say "See, I told you."

Yes, you were right..

Takes some time but changes do occur once in a while.

[MedEvil]

Peter,
this time I am serious.

I do understand the complexity of Winbuilder, but when there is a profound change to the Syntax the engine understands, it should be "advertised" with some advance.

It was advertised. Even i know, that we now have variables and macros.

The practical result is that we have right now a "better" engine, but no correct fuel to feed it with.

The new car may go faster, but right now it cannot even start, the "old" one at least was able to run, maybe with some hiccups, but actually worked.

Stop complaining and use NaughtyPE. That works!

[Galapo]

It was advertised. Even i know, that we now have variables and macros.

Maybe it was advised, but certainly not explained.

This works under pre-080 WB, but not with 080. Do you know how to get this into a macro:

[Variables]

RunFromRam=Run,%API%,Run_FromRam1



[Process]

Set,%runfrom%,RunFromRAM

%runfrom%,True

I had thoughth the idea was that variables had %, macros did not have %. So I thought this should work under 080, but it doesn't either:

[Variables]

RunFromRam=Run,%API%,Run_FromRam1



[Process]

Set,runfrom,RunFromRAM

runfrom,True

Currently I'm at a loss as to how to get macros like the above working under 080.

Thanks,
Galapo.

[Lancelot]

It was advertised. Even i know, that we now have variables and macros.

No it was not. In time, LiveXP being a close follower of wb versions, We already changed variables used as macros on LiveXP (well we could not upgrade from 77rc2, but we did not sit lazy waiting next stable release which is another known never ending story).
If you look galapo's topic, read carelfully and test closely, Galapo points a critical issue of syntax usage (variables NOT defined as macros).

anyway, I am %110 sure it will be fixed on next version.

edit:

[MedEvil]

Maybe it was advised, but certainly not explained.

This works under pre-080 WB, but not with 080. Do you know how to get this into a macro:

[Variables]

RunFromRam=Run,%API%,Run_FromRam1



[Process]

Set,%runfrom%,RunFromRAM

%runfrom%,True

Three questions Galapo.
- Are you sure your command is the problem and not the command in the CAPI?
- Why do you try to put the macro into a variable?
- Wouldn't it be smarter to use a macro name, that is not already in use for your tests?

[Wonko the Sane]

Stop complaining and use NaughtyPE. That works!

Sure, will do, of course as soon as you will sort out, with the help of the other developers which version of CAPI it is using, which one it should use, which one is the latest one, which one is the best one:
http://www.boot-land...showtopic=10376
AND you will have tested thoroughfully your project with the new release of Winbuilder, AND after I will have removed ANYTHING connected to sound and multimedia , to which I am not interested in the least, I may use it.


...on second thought, no thanks , I guess that I can use native_ex barebone without needing to remove anything.



Wonko

[MedEvil]

...on second thought, no thanks , I guess that I can use native_ex barebone without needing to remove anything.

Why again, were you complaining about LiveXP not working with WB080?

[Lancelot]

Three questions Galapo.
- Are you sure your command is the problem and not the command in the CAPI?
- Why do you try to put the macro into a variable?
- Wouldn't it be smarter to use a macro name, that is not already in use for your tests?

Let me answer :
- YES
- read topic and check relavant scripts carelfully
- how ? put an example here

and reminding:
Even not using any 078 series with LiveXP, I requested "If,ExistMacro" a month ago for a very similar case and reason where If,ExistVar naturally fails (check post 1 here). but strformat is a common syntax and there exist no way out on 080rev2. simply up to 080rev2 it is forgotten to give ability to transfer variables to macros and so told success tests (not by me or Galapo or other advanced LiveXP users) with LiveXP are made very quickly with not checking log !!!!!!!!!!!. More details and examples here .

[MedEvil]

I see, so your problem is not that you can't make the script work, but that you can't make it work by converting variables and macros forth and back, like you want to.

Can't remember Peter ever saying anything about, if that is even allowed, since variables and macros got seperated.
But i guess not, cause else there would have been little sense in seperating the two in the first place. But better ask Peter that.
If Bootland is reachable tomorrow, i bet he answers.