19 Mar
2018
19 Mar
'18
12:17 a.m.
It would be nice to avoid breaking project/config file compatibility as
much as possible.
New things can usually be added without a problem; it's changing existing
things that can be hard, and it's usually a trade-off between code
complexity and backwards compatibility.
Up to now I probably haven't given enough priority to maintaining
compatibility, especially with config; I've preferred to keep the code
reasonably nice.
It's hard to look forward and see what might need changing in the future,
so I don't think there's too much that can usefully be modified in advance
at this point.
There were a lot of internal changes in 2.11.x so I think we have to suck
it up this time. I'll be more careful in future :)
It has to be said, though, that the breakages we are talking about here
*only* (at least, I think) cause problems when loading *new* projects or
configs into *old* versions of DoM. New DoMs should be able to load old
stuff going back quite a way (even back to 1.x). As long as you upgrade
all your machines at the same time, and be careful to test the new DoM
with new projects only, I believe it should not be a massive deal (though
correct me if I'm wrong).
All the best,
Carl
On Sun, 18 Mar 2018, Carsten Kurz via DCPomatic wrote:
Hmm, Carl may not like the idea at this point - but as
2.11.x breaks
prefs and project backward compatibility - why not utilize that aspect
for good and look over some prefs/project file parameters that could be
revised for future use?
E.g. I see a (probably historic choice) boolean wrapping type parameter
that sets SMPTE by indicating Interop=0 - what if e.g. we change that to
'Wrapping' and allow more than two choices in the future to allow e.g.
specific SMPTE types to be created? That is just an example (maybe not a
good one), but since 2.11/2.12 breaks backward compatibility anyway, why
not think over it?
E.g. which changes could come up when Carl starts working on CCAPs?
New SMPTE DCPs may include more metadata options - maybe allow for
different SMPTE dialects to be created? Maybe allow encrypted SMPTE DCPs
to be created without encrypting subtitles (we should probably leave
this to be config file setting, not a GUI settable).
I may be to late with these ideas for 2.12, but then maybe for 2.13...
- Carsten
...gesendet von unterwegs
Am 18.03.2018 um 14:28 schrieb Carsten Kurz via
DCPomatic <dcpomatic(a)carlh.net>et>:
I think we should leave it as planned. I am confident that everything that worked in
2.10.5 still works in 2.12. with the exception of custom container types, but that is
something we wanted to get rid of intentionally.
We should probably include a Readme1st this time, explaining the prefs backup, signature
change and implications, and codesigning/verification delay. While DCP-o-matic is not the
only Mac app showing that delay (google finds many forum discussions around that), we
should tell people that this is normal, otherwise we will get many complaints on the
mailing list and forum, and probably also many people staying on 2.10.5 as well because
they consider the new version broken.
- Carsten
...gesendet von unterwegs
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
Am 18.03.2018 um 01:31 schrieb Carl Hetherington
<cth(a)carlh.net>et>:
Hi all,
I agree that the config file thing is not great. At the moment if you go
to 2.11.x and then back to 2.10.5 your config file will be lost (sort-of:
it's backed up next to your new one by DCP-o-matic but it's not as easy as
it could be to find).
An alternative to this would be making 2.12.0 copy your existing config
and then use its own, so if you went back to 2.10.5 you'd get your old
config and you'd have two (possibly divergent) configs.
I'm not averse to doing this for 2.12.0 if people think it's a good idea.
I'm undecided personally.
The version 3 thing feels like a workaround for an unhelpful operating
system to me, so I'm less inclined. If 2.12.0 doesn't work for you,
re-install 2.10.5: it shouldn't take long. Also I suspect 2.12.0 projects
won't load into 2.10.5 (though I haven't tested that) so encouraging
people to have multiple versions in use may not be a great idea.
I'm open to persuasion on both of these matters though!
Carl
> On Sat, 17 Mar 2018, Carsten Kurz via DCPomatic wrote:
>
> Hi Jim,
>
> 1.) you can have many versions installed in parallel on a Mac. Currently, I have
about 15 or so, each in it's own folder. This doesn't work on other platforms, at
least not easily.
> My current Applications/DOM subfolder structure is
>
> - /dcpomatic/Release/
> /dcpomatic/Test_2_11_xx
> /dcpomatic/Test_2_11_yy
> ...
>
> Occasionally, it turns out that prefs between major version bumps are not compatible,
so you need to backup your prefs once you start working with a major new release.
>
> E.g. prefs from 2.11.x are not backwards compatible with 2.10.5 Going FROM 2.10.5 to
2.11.x is no problem.
>
> If you care about prefs and certs, you need to make sure you ZIP a set of prefs for
each version. You will probably notice that you don't need to switch back to an older
version too often once you started with a new release. As newer is ALWAYS better ;-)
>
> 2.) The long Gatekeeper run is 'normal', and happens due to the new
codesigning. It only occurs with the first run of each app after installation. The good
thing is, once that has happened, you don't get the 'Allow incoming
connections' request every time you start DCP-o-matic, batch converter or encode
server. Just let it happen, one app for a time. It takes about 3-4 minutes on my machine.
One positive side effect of the code signing now also is that you don't need to
CTRL-Click the apps in order to open them initially.
>
> Getting this to work was quite some struggle for Carl, but I think it's good to
use code signing and for Carl to be a registered OS X developer. Due to increasing
security constraints on Windows and Mac platforms, DCP-o-matic would sooner or later run
into trouble without that.
>
> Now, one should be careful with such promises, but, as you see, 2.11.x so far has
seen the most test versions ever, and only VERY FEW of them were due because of the new
features, but most to iron out old and new bugs. Major bug cleanup started late last year,
so, those many test builds did make sure that there SHOULDN'T be too many bugs left.
>
> After all, 2.10.x settled on 2.10.5 for the 'final' stable release, so, of
course, 2.12 will certainly not stay on 2.12.0 for too long. But I don't think we will
see a 2.12.77...
> And keep in mind, 2.10.5 DOES contain some known bugs that are only cleaned out in
2.11.x and 2.12
>
>
> - Carsten
>
>
>
>
>
>
>
>
> _______________________________________________
> DCPomatic mailing list
> DCPomatic(a)carlh.net
> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
>
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic