[squeak-dev] The Trunk: ReleaseBuilder-eem.172.mcz
marcel.taeumel at hpi.de
Tue Jan 16 17:18:48 UTC 2018
Yes, upfront Q&A sounds good. Eventually, we might want to have some guided, interactive release building process so that any new release manager can understand the process quickly.
Speaking of unattended release building, our TravisCI does not simply call #saveAsNewRelease. See this:
It has its own version of #prepareSourceCode and just calls #prepareEnvironment afterwards.
Am 06.01.2018 18:44:17 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
First, oops, I've been sending messages in this thread to Marcel Weiher, not Marcel Taeumel. Forgive me; I of course want to talk with you Marcel Taeumel :-)
On Sat, Jan 6, 2018 at 12:12 AM, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> wrote:
what about a method like "ReleaseBuilder >> #releaseLocally"? Then put both into a category like "testing"? Would be easier to change than a class-inst-var.
Well, I suppose we could add class variables for major settings. We could provide a check-box dialog for selecting the major options. With this approach we'd get rid of the "Do you want to discard local changes?" prompt and move the asking of the question to the start of the process, avoiding having to sit there waiting for slow phases to complete to answer the prompts. So the two questions we want to ask right now are
- do you want to discard local changes?
- do you want to change the default bytecode set?
Are there others?
Am 06.01.2018 05:09:15 schrieb Eliot Miranda <eliot.miranda at gmail.com [mailto:eliot.miranda at gmail.com]>:
Hi Marcel, Hi David,
in modifying the ReleaseBuilder to allow the SistaV1 bytecode set to be selected I'm not happy having to wait until all the checking before prompting to use the bytecode set. One could move the query earlier, into setPreferences, but this means that the bytecode set would be in use before the Compiler recompileAll step, and that isn't desirable while debugging the byte code set. Would you object to me adding an instance variable to ReleaseBuilder class, useNewBytecodeSet or some such, which would be set in setPreferences and read in recompileAll?
On Fri, Jan 5, 2018 at 7:20 PM, <commits at source.squeak.org [mailto:commits at source.squeak.org]> wrote:
Eliot Miranda uploaded a new version of ReleaseBuilder to project The Trunk:
==================== Summary ====================
Time: 5 January 2018, 7:20:47.150059 pm
Allow the ReleaseBuilder to query if the SistaV1 bytecode set should be the default in a new release.
=============== Diff against ReleaseBuilder-mt.171 ===============
Item was changed:
----- Method: ReleaseBuilder class>>prepareSourceCode (in category 'preparing') -----
"Update code. Remove foreign packages."
MCMcmUpdater defaultUpdateURL: self buildRepository description.
MCMcmUpdater updateMissingPackages: true.
TestCase new ensureInternetConnectionTo: self buildRepository description.
"Flush all caches. If a previous download failed this is often helpful"
"Save the current default updater, clear the registry, and re-register the current updater"
[MCMcmUpdater default doUpdate: false. "non-interactive"]
on: MCEmptyVersion do: [:warning | warning resume].
- Compiler recompileAll.!
Item was added:
+ ----- Method: ReleaseBuilder class>>recompileAll (in category 'scripts - support') -----
+ (Smalltalk classNamed: #EncoderForSistaV1) ifNotNil:
+ CompiledCode preferredBytecodeSetEncoderClass ~~ sistaBytecodeSet ifTrue:
+ [(Project uiManager
+ confirm: 'Do you want to make it the default in this release?'
+ orCancel: [false]
+ title: 'The SistaV1 Bytecode Set Is Available') ifTrue:
+ installSecondaryBytecodeSet: sistaBytecodeSet;
+ preferredBytecodeSetEncoderClass: sistaBytecodeSet]]].
+ Compiler recompileAll!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev