Rapidweaver 8.1.2

Kent · 29 January 2019 17:16

Hello just now I updated Rapidweaver to version 8.1.2 and now it crashes when trying to open. I restart my mac and close all windows etc and it still is unable to open because it crashes. I have put my Rapidweaver back to 8.1.1 via time machine. Any other experienced the same?

Kind Regards
Kent

mitchellm · 29 January 2019 17:19

8.1.2? Where did you get it from? I have no update notice (regular or beta) about an 8.1.2 version.

isaiah · 29 January 2019 17:47

update: it just rolled out. ignore previous post.

mitchellm · 29 January 2019 18:11

Zero problems with 8.1.2. But also zero problems previously.

I believe most of the problems folks have been experiencing had to do with resources. That’s simply a feature I don’t use. I warehouse (FTP) all my resources directly to my hosting area. I do use a very small number of drag-drop images in some stacks: but that process does not seem to have been a problem for most folks.

Kent · 30 January 2019 14:34

Hello I tried update Rapidweaver again and now it is working. Do not understand what the problem was. Anyway the update is working. I also think that when all the bugs have been ironed out, I will really like Rapidweaver 8.1, actually I already like it but sometimes my weak nervous system cannot handle bugs :-)

isaiah · 21 February 2019 06:10

@kent - v8.1 introduced quite a barrage of new things. and also some significant plugin-api changes. and also a new file format. in my professional opinion, that’s a lot of new for a point release. 😬 so i think if you’re a pro managing a larger project – or several – then there’s solid rational for caution.

in software that i use professionally, i try to wait for:

all data-loss bugs to get ironed out
the rate of new reported bugs to fall off
some stability

so, how’s RW doing?

the scary resource-linking bugs in v8.1.0 seem to have been ironed out. phew.
the rate of new bugs? there are still quite a few, but it’s slower than it was. it’s a judgement call.
stability… well, there was a new build released this morning. and a recent build will trigger a new build of stacks tomorrow. so… not quit yet.
but with a little luck one of these builds will stick around for a week or two. when that happens, it’s probably safe to say, “come on in, the water’s fine.” 😉

the good news is that v8.0.3 was a pretty solid build. i still use that version of the frameworks when building the release version of Stacks. it’s a good one.

isaiah

Jannis · 21 February 2019 06:54

Something against that: backup backup backup your RW projects…

Phil · 21 February 2019 08:55

So back ups of Version 8.1.5, Version 8.1.4, Version 8.1.3, Version 8.1, Version 8.1.1, Version 8.1, Version 8.03? And some Version 7?

Jannis · 21 February 2019 09:00

Why not?

Edit: don’t shoot the messenger. Just trying to suggest ideas.

rob · 21 February 2019 10:02

so, how’s RW doing?

@Isaiah Thanks for this post! My regular readers (rapidweaver.ninja) expect me to review new releases as soon as they become available. As such, I installed to RW 8 as soon as it was released as a Beta. I don’t mind testing beta software, it can actually be fun and I’ve tested betas from numerous LARGE companies, Apple, Adobe, Quark.Inc included.

What I don’t consider fair to the users is when an app is released as “Final” and then continues to issue Beta 0.1; 0.2; 0.3 “Final, Final, Final Releases”.

I don’t mind waiting until an app has reached a ‘final’ stable version before committing to a purchase, or an upgrade.
And if the Golden Master (which Realmac has obviously never heard of) proves to be buggy, I expect it to be withdrawn and will wait for the Golden Master II! Remember OS X GM00.1??

I’ve used RW since it’s earliest beta release and after experiencing several buggy updates (most especially 6—7 and 7—8) I’m becoming disheartened by the products being pushed by Realmac.

In my opinion, it’s unfair to allow regular users to test beta products. Test; test again until the users have finally identified a ‘stable’ product – this is simply not the way that a professional software smithy works.

For my ‘professional’ websites I still use RW7.x.
I’m still waiting for “come on in, the water’s fine”. And this announcement for RW8 doesn’t look as if it 's coming any time soon.

Happy Beta Testing!!

isaiah · 21 February 2019 15:10

this is a well considered position. 👍 and you are certainly not alone.

and this is why Stacks 4 will include RW 7 support.

hopefully Stacks 4 will be stable a bit more quickly than all that.

Webdeersign · 21 February 2019 15:29

As Billy Connelly would say, TicketyF**ketyBoo. Great news.

isaiah · 21 February 2019 16:24

I know it’s hard to believe, but currently Stacks offers RW 6 support. So moving to RW7 support feels like Mel Gibson yelling: FREEDOM – i can do so much more now.

That said, I have to drop at least one large feature for RW7. Booo!!! I hate doing this. 😡 But there’s just no nice way around it.

We’ll have a nice warehouse image stack that uses RW resources to do the warehousing bit.

Basically an image stack that always references a resource that’s only published once for the whole site, only loaded in memory a single time, and only as part of the project – not each page.

Warehousing AND doing it with resources. It’s a HUGE win for memory, for publishing, for loading time, for preview time, and… well you know… everything.

But RW7 has basically no API for resources.

(╯°□°）╯︵ ┻━┻

So on RW7 that stack just won’t appear. Bummer I know.

Webdeersign · 21 February 2019 16:27

So are you saying the new S4 image function to use resources will not be present for RW7 with S4 but everything else will?

isaiah · 21 February 2019 16:49

@Webdeersign - pretty much. “everything else” is nearly true, but not quite.

there are always lots and lots of tiny differences between different versions of RW. however these are normally either cosmetic or workflow features – transparency, window shapes, button positions, etc.

Stacks 4 will have two big things that are version dependent:

Dark mode requires Mojave (this one is pretty obvious)
Resource Images (warehousing) requires RW 8.

It’s a significant omission, though. And I think the first time I’ve ever included a functionality difference between RW versions. I try really hard to avoid that – but in this case the alternatives were terrible.

either huge extra dev time + schedule delay OR drop feature for everyone. yuck and double-yuck.

Webdeersign · 21 February 2019 16:54

Thanks for this information. Neither the dark mode or resources are of any interest to me, so that’s perfectly fine.

mitchellm · 21 February 2019 16:59

@isaiah OMG! This is fantastic!

My question: there’s at least 3 ways to get images uploaded:

drag and drop into a stacks window (or whatever is the official word)
use resources
directly FTP yourself and copy relevant URL link with Transmit or other app

Does this new capability change anything about drag/drop types of image stacks? Will it be possible to “drag” a resource into a drag/drop area? Sorry, I don’t use resources at all. Just FTP. But there are some image based stacks I use once in awhile that only offer drag/drop options. Would be beautiful if they could also take advantage of this new feature. If so, that solves a LOT of problems/workarounds.

Jannis · 21 February 2019 17:00

I hope I am able to get Repository Stack to make this happen also (either with clipboard link, or drag and drop a icon to the Stack)

mitchellm · 21 February 2019 17:06

@Jannis That would be sweet! Repository is a “must have” stack already. That would make it even better.

isaiah · 21 February 2019 17:27

I won’t be able to answer this question with confidence until after I let the developers have Stacks for a bit. And currently only a tiny few have seen a very alpha version. So I don’t really know.

Obviously if a stack only exists in one location at one size, this lops off quite a few stacks image api features. lets see… transforms, scales, crops, shadows, borders, retina-export, format-conversion, jpeg-compression… i think that’s probably all of them.

3rd party stacks that rely on those features obviously can’t use these new images. but there are actually not that many of those, to be honest. and for that reason, i’ve left this very open for now. i’m basically going to give the stuff to the stack developers and see what breaks. then see if we can find the most minimally invasive fix.

there are lots more caveats i could go into. but the hope is that it will work in “most” places. what “most” really is, i don’t quite know yet. give me a few weeks and i should have an answer.

isaiah