issue-#14: Blackbox building pipeline
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
issue-#14: Blackbox building pipeline
I am working on creation of pipeline for building BlackBox Setup Binary from the sources. Marc Frei shared Inno Setup script used in Oberon microsystems for compiling setup file for BlackBox. I added compression, that allowed to reduce Setup size to 5 Mb. I changed publisher information and web-site.
http://blackboxframework.org/dev/blackb ... -setup.exe
Also I improved the Icon: Do you like this variant?
I am offering to replace download file in the front page:
http://blackboxframework.org/
http://blackboxframework.org/dev/blackb ... -setup.exe
Also I improved the Icon: Do you like this variant?
I am offering to replace download file in the front page:
http://blackboxframework.org/
- Attachments
-
- BlackBox.iss.zip
- (7.99 KiB) Downloaded 533 times
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: blackbox-1.6-setup
Ivan,
That seems to work correctly.
I downloaded and install over my previous copy of BB and have briefly tested it.
Seems fine to me.
Is the icon change simply to draw a distinction between Omic and Center?
-Doug
That seems to work correctly.
I downloaded and install over my previous copy of BB and have briefly tested it.
Seems fine to me.
Is the icon change simply to draw a distinction between Omic and Center?
-Doug
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: blackbox-1.6-setup
Yes, now the icon is the only difference. Also it has better resolution and seems more modern.DGDanforth wrote:Is the icon change simply to draw a distinction between Omic and Center?
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: blackbox-1.6-setup
1.6 should be left unchanged. Changes should go into the forthcoming center release 1.7. What has been released by ominc is not to be changed by the center without a strong need.
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: blackbox-1.6-setup
I agree. How we will enumerate development builds?Josef Templ wrote:1.6 should be left unchanged. Changes should go into the forthcoming center release 1.7. What has been released by ominc is not to be changed by the center without a strong need.
blackbox-1.7.0.001-setup for some initial alpha?
http://en.wikipedia.org/wiki/Software_versioning
wiki wrote:Designating development stage
Some schemes use a zero in the first sequence to designate alpha or beta status for releases that are not stable enough for general or practical deployment and are intended for testing or internal use only.
It can be used in the third position:
0 for alpha (status)
1 for beta (status)
2 for release candidate
3 for (final) release
For instance:
1.2.0.1 instead of 1.2-a1
1.2.1.2 instead of 1.2-b2 (beta with some bug fixes)
1.2.2.3 instead of 1.2-rc3 (release candidate)
1.2.3.0 instead of 1.2-r (commercial distribution)
1.2.3.5 instead of 1.2-r5 (commercial distribution with many bug fixes)
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: blackbox-1.6-setup
In my understanding ominc already applied a three level numbering schema x.y.z to
BlackBox releases.
x is the major version number changed only in case of major incompatibilities at the source level.
y is incremented whenever a binary incompatible release is published, thus you need to recompile
your programs but there is no (or almost no) change in the source code required.
z is the patch level, i.e. small changes within x.y that are binary compatible.
We should stick with this schema.
Now with the proposed CPC 1.7 changes there is a bug fix with the fingerprint computation,
which produces new binaries. That is why we use 1.7.0 and not 1.6.1, provided that we
keep this bug fix, of course.
For the additional information (alpha, beta, release candidate)
we must introduce additional dimensions such as
x.y.z-<state>[<n>].<buildnr>
where
<state> is one of
a alpha state; under development, not feature complete
b beta state; under development, feature complete, internal testing
rc release candidate state; external testing
<n> is a number, we will probably only need it for release candidates.
<buildnr> is a sequential number incremented per build by the build machine.
The build machine cannot know the build state.
So we must provided this information by means of
a file (buildstate.txt, or similar) in the repository root.
The contents would be "1.7.0-a.$(buildnr)", for example,
where $(buildnr) is replaced by the build machine.
By looking at the history of this file one can easily reconstruct the timeline
of the release history.
- Josef
BlackBox releases.
x is the major version number changed only in case of major incompatibilities at the source level.
y is incremented whenever a binary incompatible release is published, thus you need to recompile
your programs but there is no (or almost no) change in the source code required.
z is the patch level, i.e. small changes within x.y that are binary compatible.
We should stick with this schema.
Now with the proposed CPC 1.7 changes there is a bug fix with the fingerprint computation,
which produces new binaries. That is why we use 1.7.0 and not 1.6.1, provided that we
keep this bug fix, of course.
For the additional information (alpha, beta, release candidate)
we must introduce additional dimensions such as
x.y.z-<state>[<n>].<buildnr>
where
<state> is one of
a alpha state; under development, not feature complete
b beta state; under development, feature complete, internal testing
rc release candidate state; external testing
<n> is a number, we will probably only need it for release candidates.
<buildnr> is a sequential number incremented per build by the build machine.
The build machine cannot know the build state.
So we must provided this information by means of
a file (buildstate.txt, or similar) in the repository root.
The contents would be "1.7.0-a.$(buildnr)", for example,
where $(buildnr) is replaced by the build machine.
By looking at the history of this file one can easily reconstruct the timeline
of the release history.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: blackbox-1.6-setup
Lets analyse: 1.6rc6
x = 1
y = 6
<state> = rc
<n> = 6
There are no 'z' in Ominc scheme, 'z' and 'build number' duplicate function, new build automatically means some small changes in code?
so, the next setup will be
blackbox-1.7-a1.001-setup.exe ?
Or I misunderstood something?
x = 1
y = 6
<state> = rc
<n> = 6
There are no 'z' in Ominc scheme, 'z' and 'build number' duplicate function, new build automatically means some small changes in code?
so, the next setup will be
blackbox-1.7-a1.001-setup.exe ?
Or I misunderstood something?
-
- Posts: 204
- Joined: Wed Sep 18, 2013 10:06 pm
- Contact:
Re: blackbox-1.6-setup
While on the topic of version numbering both the setup.exe and / or the BlackBox.exe file should have their file properties maintained as part of the build process to identify their version number etc. You should not have to install or run an application to be able to determine what version it is. The properties of the BlackBox setup file are mostly OK except for the missing copyright notice and file version.
However, the BlackBox exe has no proper identification at all:
These attributes are usually assigned by the Setup builder application. I use Lindersoft's SetupBuilder myself for this sort of thing but would expect Inno Setup to have the necessary capabilities.- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: blackbox-1.6-setup
Ohh, you are right. I mixed things up.
Back in the BB 1.4 time there was a service pack being delivered,
named BlackBox 1.4 Service Pack 1.
There may have been multiple such service packs, I cannot recover this in detail.
In any case, it should be possible to distribute minor binary compatible updates
(bug fixes), named as service pack or whatever.
For the forthcoming center release it would be sufficient to number it 1.7.
Back in the BB 1.4 time there was a service pack being delivered,
named BlackBox 1.4 Service Pack 1.
There may have been multiple such service packs, I cannot recover this in detail.
In any case, it should be possible to distribute minor binary compatible updates
(bug fixes), named as service pack or whatever.
For the forthcoming center release it would be sufficient to number it 1.7.
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: blackbox-1.6-setup
I have tested the command line compiler at the server side and it works well.
http://redmine.blackboxframework.org/issues/2
http://redmine.blackboxframework.org/issues/2