Xcode 6 and bltrversion

[Rob McBroom]

I assume it started with Xcode 6, anyway.

As described in the Plug-in reference (2nd bullet point), bltrversion used to run after the product was spit out. It now appears to run before. As a result, we’ve got a few plug-ins out there with a build number higher than what you see in the repo.

So going forward, we need to:

• Check the build number of the released plug-in before putting out an update, then make sure any new release it higher.
• Check the build number of newly built plug-ins to make sure it’s what you expect it to be.
• Commit the “real” build number, then manually decrease it by 1 before doing a release build so ti will end up back on the real number.

An alternative to that last one: We could just know that it works this way and release plug-ins with higher numbers than what’s in the repo, but I hate that idea.

Another option (which I’m sort of leaning toward) is removing the build number fiddling from the script altogether and just doing it by hand. (We end up messing with it by hand all the time as it is. At least we could eliminate surprises.)

--
Rob McBroom
http://www.skurfer.com/

[Patrick Robertson]

So for the Extra Scripts plugin I just built, it has a version number of 93 and Info.plist has 94. I think that Info.plist and the released plugin should have the *same* version number (that's what I always assumed was the case).

Rob - are you saying that this is what is happening now (since bltrversion is being run before the plugin gets created).

If we just stick to blindly listening to bltrversion, what's the problem?

--
You received this message because you are subscribed to the Google Groups "Quicksilver - Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quicksilver---deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob McBroom]

On 17 Sep 2015, at 2:50, Patrick Robertson wrote:

So for the Extra Scripts plugin I just built, it has a version number of 93
and Info.plist has 94. I think that Info.plist and the released plugin

should have the same version number (that's what I always assumed was the
case).

Rob - are you saying that this is what is happening now (since bltrversion
is being run before the plugin gets created).

If we just stick to blindly listening to bltrversion, what's the problem?

Say you clone a fresh copy of the repo and the build number in Info.plist is 93. You build the plug-in…

Before

1. Info.plist is copied into the final product (still at 93)
2. bltrversion runs, making whatever changes
3. The build number is now 94 in the project, but that was never committed

Now

1. bltrversion runs, making whatever changes
2. Info.plist is copied into the final product (now at 94)
3. The build number is now 94 in the project, but that was never committed

The new way is what we always wanted (so documentation changes, etc. would be included in the final product immediately), but it’s problematic because the plug-in you build ends up with a higher number than what you have in the repo.

Maybe we just need to adjust the work-flow and not commit changes to Info.plist until after we build the final release, but that only works if the person making the changes is also releasing the plug-in which isn’t always the case.

In theory, anyone should be able to check out a fresh copy of the project and build something that matches what’s released. That isn’t the case now. I guess that’s the problem. (Also, if you work on a plug-in and build in Debug mode, the version won’t get bumped. What you have will be 1 less than what was released, so the new build won’t replace your copy of the plug-in.)

Bottom line: We have to change the user-friendly version anyway, and we end up fiddling with the build number (rolling it back, pre-setting it to one less) a lot anyway, so why not just manage it by hand?

[Patrick Robertson]

Aaah I get you now. Yeah this is a problem.

Can we change the workflow so that whoever releases a plugin *must* also commit? This isn't ideal as you say.

Also - in recent years I've kind of been fiddling with the build number less and less. What's the point in fiddling with it *really*?

If it's enabled in Debug (which would solve our "you forgot to update the documentation in Info.plist" problem we get) then we can just let it do its thing. Does it matter if the build number in 2 year's time is FFFF?

--

[Etienne Samson]

My opinion would be that the person responsible for doing the release would handle the "commit updated Info.plist' part, else we'd be skipping (un)released/development versions.

I've been thinking more and more about rebuilding the Xcode project from scratch — I mean, it was done years ago, in ancient times where Xcode wasn't able to get its Products together (the existence of the /tmp/QS workaround being the demonstration of this), didn't have Workspaces, etc. We now have Shared Build Products that *might* work how I wanted them to, like 5 year before they were available ;-).

Maybe we should move bltrversion out of the Build Script phase completely ? So the "Release Manager" can increment the version before the final build and commit/tag that, and "Developers" don't mess with the Info.plist. Maybe model bltrversion more like how agvtool(1) works ?

Regards,
Etienne Samson
--
samson....@gmail.com

[Rob McBroom]

On 17 Sep 2015, at 22:43, Patrick Robertson wrote:

> Can we change the workflow so that whoever releases a plugin *must*
> also
> commit? This isn't ideal as you say.

What if you’re just building it locally to test something? If you just
clone/update the repo and build, what you get doesn’t match what’s
released.

> If it's enabled in Debug (which would solve our "you forgot to update
> the
> documentation in Info.plist" problem we get) then we can just let it
> do its
> thing. Does it matter if the build number in 2 year's time is FFFF?

But you STILL need to manually change the user-visible version. So why
not just change the build number too at the same time?

I’ll make the change and submit a pull request.

[Rob McBroom]

On 18 Sep 2015, at 8:13, Etienne Samson wrote:

> My opinion would be that the person responsible for doing the release
> would handle the "commit updated Info.plist' part, else we'd be
> skipping (un)released/development versions.

I’d like the dev to do it. (But how often are those different people.)

The exception is tagging. That should be done by the person that merges,
because we won’t know until that moment if that version is truly done.

> I've been thinking more and more about rebuilding the Xcode project
> from scratch — I mean, it was done years ago, in ancient times where
> Xcode wasn't able to get its Products together (the existence of the
> /tmp/QS workaround being the demonstration of this), didn't have
> Workspaces, etc. We now have Shared Build Products that *might* work
> how I wanted them to, like 5 year before they were available ;-).

If you do that, let us have a look. :-)

> Maybe we should move bltrversion out of the Build Script phase
> completely ? So the "Release Manager" can increment the version before
> the final build and commit/tag that, and "Developers" don't mess with
> the Info.plist. Maybe model bltrversion more like how agvtool(1) works
> ?

I’m not opposed, if we can make it easy to run manually. Then, you
would only run it when the documentation is updated, or before your last
commit on a new PR branch. We could also make it take a user-friendly
version as an argument so you could just set that in one step at the
end.

There’s still the problem of Xcode and `plistlib` wanting to put the
file in a different order. So, personally, I would also run it after
every Xcode-based change to the plist to reorder it the `bltrversion`
way.