[Scons-dev] Questions about the SCons release process.
William Blevins
wblevins001 at gmail.com
Tue Aug 12 11:31:18 EDT 2014
>
> On 12.08.2014 01:46, William Blevins wrote:
>> Is this a good model for project releases? In this case, the reason for
>> releasing an update is to fix a VERY specific issue. Wouldn't it be better
>> to release with a patch fix on top of branch rel_2.3.2 as 2.3.2-2 rather
>> than release everything current in default which may include changes
>> intended for SCons 3.X?
>
> I understand your concerns, but I don't see any changes in the diff
> 2.3.2-current that would break Python2.x compatibility. So I'd like to
> continue with release numbering as normal, everything else might confuse
> the user.
Will the next SCons update (SCons 2.3.3) be released from default based?
> Based on the current commit workflow this seems to be the case.
>
>From 2.3.0 was compatible with 2.4+, but 2.3.1+ is only compatible with
2.6+. It just seems "peculiar" for a patch version to change python
compatibility.
> I still think that we really have enough workflows, now we actually have
> to do wome work. Boring, I know...it's so much more fun to fiddle with tech
> stuff and new interfaces while migrating from one technology to the other.
> ;)
I think you mean step back and do stability related work: docs, testing,
minor bug fixes, etc. Do we have official development cycle markers or any
form of indicator as to current SCons development focus?
BTW, the OpenHatch project just migrated its issues from Roundup to Github,
> because with having the tracker close to the sources they would "save so
> much work". They wrote scripts and did all their stuff, and now the first
> users complain because Github doesn't have a notion of "depends on", for
> example. Lots of hours down the drain basically, and let me just add: I
> warned them in advance...
> I don't want the same thing happening to us, our resources are still to
> scarce.
<Topic swap>
I'm not arguing the effort in a change like that nor the risk of any change
(no matter how small). I'm not sure how the Github tracker compares with
Roundup; they may have moved to a subpar tracker and I could see that being
an issue. Maybe the convenience gain wasn't worth the loss? I cannot
judge, but keep in mind that people reserve the right to complain,
regardless of whether those complaints are justified. You cannot please
everyone, and it would be insane to try.
Further off-topic, I heard (maybe from Gary?) SCons may move from Tigris to
Roundup. I'm not sure where this stands.
> Releasing/branching off from default is an industry standard.
I think we are in agreement here and my example was just too vague. Let me
try to be a bit more specific, so I can validate. The following quotation
is how I imagine the industry standard (including SCons) for version
numbers.
" " "
*Some projects use the major version number to indicate incompatible
releases. Two examples are Apache APR[6] and the FarCry CMS.[7] Semantic
Versioning[8] is a formal convention for specifying compatibility using a
three-part version number: major version; minor version; and patch. The
patch number is incremented for minor changes and bug fixes which do not
change the software's API. The minor version is incremented for releases
which add new, but backward-compatible, API features, and the major version
is incremented for API changes which are not backward-compatible. For
example, software which relies on version 2.1.5 of an API is compatible
with version 2.2.3, but -not necessarily- with 3.2.4.*
" " "
With SCons, at least in recent releases, the patch number hasn't been
honored as bug fix only, and I am concerned this is creating some confusion
for user's with focus on stability.
For example, if we released a 2.3.3, then I imagine the only change would
be bug fixes (E.G. the fix for D tools affecting C tools). Since there are
currently commits in default that affect the API, regardless of how small
they might be (E.G. Issue 2395 updates), currently delivering a 2.3.3 from
default would break the patch number paradigm. If we deliver from default
as 2.4.0, then we are essentially leaving 2.3.X as a broken release line.
SCons has a very large public API, so being that strict on versions may
not be reasonable.
This is why I think that *always* releasing from default can cause
problems. It's also why I question Mercurial's overhead for branches
because I believe they are necessary for managing releases, and sometimes
they may only have 1 or 2 simple commits.
I imagine that the SCons repo branches might look something like this:
Legend [ '/' = new branch for tighter scope work, '-' = commits on a
branch, '\' = merge into broader scoped branch ]
2.1.X ---- 2.2.X ---
/ \ / \
2.X core ------------------------------
/ \ \
Default (IE. 3.X core) ------------------------------------------------
Sorry if that ASCII is a bit crude.
V/R,
William
On Tue, Aug 12, 2014 at 3:18 AM, Dirk Bächle <tshortik at gmx.de> wrote:
> William,
>
>
> On 12.08.2014 01:46, William Blevins wrote:
>
>> Will the next SCons update (SCons 2.3.3) be released from default based?
>> Based on the current commit workflow this seems to be the case.
>>
>> Is this a good model for project releases? In this case, the reason for
>> releasing an update is to fix a VERY specific issue. Wouldn't it be better
>> to release with a patch fix on top of branch rel_2.3.2 as 2.3.2-2 rather
>> than release everything current in default which may include changes
>> intended for SCons 3.X?
>>
> I understand your concerns, but I don't see any changes in the diff
> 2.3.2-current that would break Python2.x compatibility. So I'd like to
> continue with release numbering as normal, everything else might confuse
> the user.
>
>
>> I am concerned that the leading contributor to SCons 2.X instability,
>> including breaking pre-2.7 compatibility, is the lack of separation between
>> 2.X baselines and 3.X. Maybe there needs to be a workflow developed for
>> this?
>>
> I still think that we really have enough workflows, now we actually have
> to do wome work. Boring, I know...it's so much more fun to fiddle with tech
> stuff and new interfaces while migrating from one technology to the other.
> ;)
>
> BTW, the OpenHatch project just migrated its issues from Roundup to
> Github, because with having the tracker close to the sources they would
> "save so much work". They wrote scripts and did all their stuff, and now
> the first users complain because Github doesn't have a notion of "depends
> on", for example. Lots of hours down the drain basically, and let me just
> add: I warned them in advance...
> I don't want the same thing happening to us, our resources are still to
> scarce.
>
> We might consider handling version releases more like the python release
>> model (or some other industry-standard-like release model).
>>
>> Releasing/branching off from default is an industry standard.
>
>
> Maybe I am misunderstanding. We are releasing SCons 2.3.3 from default,
>> please consider merging pull request #164 to improve the documentation on
>> http://scons.tigris.org/issues/show_bug.cgi?id=2395
>>
>> I saw your documentation PRs, and I'll make sure that they go in before
> the release.
>
> Regards,
>
> Dirk
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> http://two.pairlist.net/mailman/listinfo/scons-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140812/d5fcd27b/attachment-0001.html>
More information about the Scons-dev
mailing list