Designer latest Beta is not working anymore. Crashing at starting up.

[albertkinng]

I created a document using the Beta version, quit the app and when I double-clicked the document it crashed. I tried to start the app after that and it's impossible. Now I can't even open the doc in the stable version. (That needs to be fixed for issues like this one, I think if we're using a beta we still can open the doc in the stable version as well or the doc will be lost forever!) Here's a video and a copy of the report.

report.txt

[Pauls]

this is due to the recent file list - see this post on how to get around it

[albertkinng]

52 minutes ago, Pauls said:

This is due to the recent file list.

Thanks! I guess your post was helpful if I found it first, but I deleted the app and re-installed it. That fix the whole problem. My guess they need to work with the update engine, it messed up the app after. Remember, not all users are going to be happy if they need to work around the terminal or library to fix things, so they will not use Inkscape on Linux.

[albertkinng]

@Pauls Any updates on opening beta files on stable version? This rule of blocking is good for stable versions but in Beta it is kind of unhelpful.

[walt.farrell]

49 minutes ago, albertkinng said:

@Pauls Any updates on opening beta files on stable version? This rule of blocking is good for stable versions but in Beta it is kind of unhelpful.

I'm not Paul, obviously. And I can only base my comments on observations and things Serif has said previously.

Generally in V1 if you had two releases, 1.x and 1.y, where x > y, then the file formats were not compatible. Thus, 1.9.something files could not be read by 1.8, and 1.8.something files could not be read by 1.7.

We should expect the same to be true in V2. So, with 2.1.something, a 2.0release will not be able to read the files as the formats are incompatible since 1 > 0.

However, once 2.1.0 is released, if there is a 2.1.1 beta, then 2.1.0 should be able to read the 2.1.1 beta files, or 2.1.2 beta files, etc.

[albertkinng]

24 minutes ago, walt.farrell said:

However, once 2.1.0 is released, if there is a 2.1.1 beta, then 2.1.0 should be able to read the 2.1.1 beta files, or 2.1.2 beta files, etc.

Exactly. That's not happening. What I said in my original post that reads wrong? Help me with the wording, so I can be more accurate about this issue.

[walt.farrell]

6 minutes ago, albertkinng said:

That's not happening.

What isn't happening? I said that 2.0 cannot (and will not be able to) read 2.1  Beta or release Affinity files.  What you're asking for won't work until/unless there is a 2.1.1 beta, at which point we can expect that 2.1.0 will be able to read its files. This is standard Serif handling for file compatibility. Major releases (2.x vs 2.y, where x > y) are not backward compatible. Only minor releases (2.x.something vs 2.x.something_else) are backward compatible.

[albertkinng]

13 minutes ago, albertkinng said:

However, once 2.1.0 is released, if there is a 2.1.1 beta, then 2.1.0 should be able to read the 2.1.1 beta files, or 2.1.2 beta files, etc.

English is not my main language but "should be able to" is not the same as "shouldn't be able to" It clearly says 2.1.0 should be able to read the 2.1.1 beta. Now you got me confused, mate.

[walt.farrell]

18 minutes ago, albertkinng said:

English is not my main language but "should be able to" is not the same as "shouldn't be able to" It clearly says 2.1.0 should be able to read the 2.1.1 beta. Now you got me confused, mate.

We are currently testing the 2.1.0 beta. When it is released, and when there is a 2.1.1 beta, 2.1.0 should be able to read 2.1.1 beta files, because 2.1.0 and 2.1.1 have the same major release number: 1.

The current retail release is 2.0.something (2.0.4, on Windows). 2.0 cannot read 2.1 files because the major release numbers are different (0, 1), and 0 < 1.

Basically, that second number, after the first "." in the release number, changes when the file formats are different enough that they are no longer backward compatible (that is, the older release can no longer read the newer release's files).

[albertkinng]

9 minutes ago, walt.farrell said:

Basically, that second number, after the first "." in the release number, changes when the file formats are different enough that they are no longer backward compatible (that is, the older release can no longer read the newer release's files).

As always, we ended up mixing topics and the main issue got lost in translation. 

1. My post was referring to opening a file that was created by the Beta, and not being able to open it with the same version. 

2. My off-topic opinion was related to the fact that the beta app version only allowed the beta-made document to be opened, leaving me with a useless document.

In my logic and based on yours too, higher numbers leave lower numbers obsolete. However, if I apply that logic literally (that was my mistake, obviously) a stable version is an Alpha and even if the Beta is 12.1 it still is lower than Alpha 1.0, so it must be at least 12.1. So, for some reason I was expecting the stable version to always open the beta documents.

I thought you were talking about my real problem and not about my off-topic opinion. That was why we tangled here about being able and not able to do a thing.

Thanks for the explanation.

[walt.farrell]

27 minutes ago, albertkinng said:

However, if I apply that logic literally (that was my mistake, obviously) a stable version is an Alpha and even if the Beta is 12.1 it still is lower than Alpha 1.0, so it must be at least 12.1. So, for some reason I was expecting the stable version to always open the beta documents.

"Alpha" is not correct in this discussion. In software development, you generally have a stable version, followed by an alpha version that is the initial coding of the next release, followed by beta versions that are subsequent codings of the next release, followed by a new stable version. We do not see the alpha versions of the Affinity applications. Those are only seen by the Serif staff. We see stable releases, and beta releases.

If we look back at V1, for example, and we look at Designer for Windows, and start with 1.8, we had:

• The release/stable 1.8.0 (version 1, release 8, modification (my term) 0. The general format is v.x.y.b where v is the version number (e.g., 1), x is the release number (e.g., 8), y is a modification number (e.g., 0, 1, 2, ...) and b is a build number (e.g., something like 1540 or 1670 or (now) 1714.
• Usually the retail/stable does not mention the build number. When it's stable/retail it's just known by v.x.y.)
• Betas for 1.8.1 (1.8.1.b where b is again the Build number). Probably we had several of those. Then
• Release/stable 1.8.1 and then
• Betas for 1.8.2 (1.8.2.b where b is a Build number). Again, probably several of those. Then
• Release/stable 1.8.2 and then
• Betas for 1.8.3, and this continued iterating until finally we had
• Release/stable 1.8.5. For all of this time, back to 1.8.0, the release/stable version 1.8.y, was able to read the 1.8 beta files.
• After 1.8.5, we had betas for 1.9.0. As 9 > 8, the release/stable 1.8.y versions cannot read the files created by the 1.9 betas.
• We then had various 1.9.y releases and betas, and the stable 1.9.y releases could read the 1.9 beta files.
• We then had 1.10 betas and stable/release versions.
• Then we got 2.0, and 1.x releases cannot read 2.x files, because 2 > 1.
• We had a small number of 2.0 releases (for Designer, on Windows), 2.0.3 and 2.0.4. The file formats are compatible because 2 = 2 and 0 = 0.
• Now we have 2.1.0.b betas, and the stable release is 2.0.4 and 2.0.4 cannot read 2.1.0 files because 1 > 0.
• Eventually we will have a 2.1.0 stable/release version, and it should be able to read the 2.1.0 beta files, because at that point they have the same release number, 1.
• We may have several releases like 2.1.1, 2.1.2, 2.1.3, etc. and during all that time and any betas that happen, the stable release programs should be able to read the beta files. Until at some point we will get a
• 2.2.0 beta. At that point, the stable programs (2.1.something) will not be able to read the beta files (2.2).

 

[albertkinng]

37 minutes ago, walt.farrell said:

"Alpha" is not correct in this discussion

That is why I said "My Mistake Obviously". I realized that before your reply. What you thought I was referring to?

[debraspicher]

All the above discussion aside, there is another workaround. You may be able to copy and paste elements into the older version(s) of the program from newer. Depending on what it is, it "should" paste fine. I've read on here some newer features may even paste gracefully enough to be suitable... again, from what I had read here in the past. There's always the unforeseen. That said, never use beta for production-level work.

In fact, I just took a document I was working on from Designer beta right now to non-beta Designer. Copy & pasted from beta to non-beta and it imports fine. It even retained object types. Even copied an entire art-board. Is it pixel-aligned? I have no idea. But it copies lol. This document only uses basic features, so I'm sure there's some caveat somewhere. Anyway, when in doubt, just try things for yourself to be sure.

If you we're playing around in beta and happened to accidentally make a Picasso, at least now you know what to do.

[walt.farrell]

2 hours ago, albertkinng said:

That is why I said "My Mistake Obviously". I realized that before your reply. What you thought I was referring to?

Sorry; I'm no longer sure, but it seemed that your terminology and understanding was still wrong. My mistake.

 

37 minutes ago, debraspicher said:

That said, never use beta for production-level work.

Right. The betas should be used for testing and playing, only. There is no guarantee they will work, or continue to work, and using them for anything other than testing and play is very risky.

[albertkinng]

57 minutes ago, debraspicher said:

That said, never use beta for production-level work.

That's a number one rule for Beta testing. I like to bring the scenario to real-life situations, so the struggle of the issue can be also part of the problem found. None of my works are done in the Beta versions, but I do like to recreate them in Beta to see what will happens. Like this example. The only way to save the work was uninstalling and re-installing the app. All my originals are saved in the stable version. To be honest, if I try the beta just for trying I will never encounter any real issue, that's why I recreate a real project. Hope I can explain myself well with this comment. English is hard.

[debraspicher]

I don't think anyone would disagree with you that it's hard to really "try" a beta without putting it through its paces. We just struggle to let other users know they are assuming some risk since some customers do move to beta as a "fix" for some other software woes they are having in the stable. If you're aware of all that, then I say do what you will do.

I tend to work on files meant more for purposes than "output" (things not for publishing/finals) because those do matter in projects and they're not something I can't remake since they're basically the early details. Using stable-sourced templates are actually really helpful for this. Can do some project planning there and just start that portion in beta. I try to make the materials in stable, but then load them in beta to parse them together for a draft. That would cover most use cases in terms of finding a bug and just tweaking things should show even more. But like I say, if you have some great design you start there you need in stable, you can copy&paste most things in (it seems...)