ETA of 1.0 or Roadmap ?

[MLefebvreICO]

Hi there,

Just found out about svelte and so far I really enjoy it.
A collegue told me about sapper, but I was wondering, if you guys have an ETA on when we can expect 1,0 or a least some sort of visual plan we can see to see what's missing ?

We are currently working with AngularJS at my workplace and are looking on the long term to upgrade framework with my boss prefering we upgrade to Angular 2+ and me not really liking the API it has, I would like to propose sapper instead.

[gavindoughtie]

It would be nice to have a single place to go look for "how's the Sapper/Svelte3 work going? How can I help?"

[antony]

I guess this comes down to what your expectation of 1.0 is. I've been using 0.24 in production for a long time, because it does everything I'd expect of it.

I think releasing 1.0.0 of something might provide a certain feeling of "completion" but I don't think it relates to anything in real life. I would suggest that you assess the framework based on what you expect of it and determine if it matches your requirements, rather than fixating on a major version number bump.

[MLefebvreICO]

@antony Except in the docs, you can read Sapper is in early development, and some things may change before we hit version 1.0.

We have a big in-house library that we need to make the switch so switching now seems like a bad idea to only confront later with some breaking API changes that will require some more time to fix.

We want something stable to build on, not something that is currently build from the ground up and may impact us negatively.

[aislanmaia]

My question looking at Sapper is just one: Is Sapper already compatible with Svelte v3 ? If it doesn't, where I can look to see the roadmap for this? I have discovered Svelte 3 and I'm having fun trying it, but Sapper is something I will touch only when it is compatible with Svelte 3.
I wont go to Svelte v2 just because Sapper.

[pngwn]

@aislanmaia Yes, it is.

[antony]

@MLefebvreICO The API has remained fairly consistent since it's inception, and there is no formal roadmap that I am aware of. Perhaps it would be a nice thing to have, but I'm not sure exactly how such a thing would come about.

I currently have three large applications live in Sapper, I have done for more than a year, and the upgrades between Sapper versions have been trivial.

[andykais]

it does appear that there is a 1.0 milestone but it is empty so I am guessing it is unused 😞

[goldo]

Does it mean that sapper isn't production-ready ? Usually 1.0 is also meaning that it is

[MLefebvreICO]

@goldo I don't think so, but the API could greatly change with 1.0, so for my part, I prefer to wait.

On their blog, they mention : Sapper is in early development, and some things may change before we hit version 1.0.

[goldo]

Ok, thanks for the clarification.

…

On Nov 11, 2019 at 4:00 PM, <Maxime Lefebvre ***@***.***)> wrote: @goldo (https://github.com/goldo) I don't think so, but the API could greatly change with 1.0, so for my part, I prefer to wait. On their blog, they mention : Sapper is in early development, and some things may change before we hit version 1.0. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (#656?email_source=notifications&email_token=AAD6WESIN44DSFVFSNPRDVTQTFXSPA5CNFSM4HKU7G4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDXCWVQ#issuecomment-552479574), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAD6WEXSNCXKG2WHWDN362TQTFXSPANCNFSM4HKU7G4A).

[antony]

To be clear, there isn't a fixation on version numbers. We could happily bump it to 1.0 without any further changes. I've been using it in production for more than 2 years and I don't have any issues.

1.0 would imply that we wouldn't make backwards-incompatible changes to the API without moving to 2.0. It suggests that the API is still potentially in flux. There are however a good number of Sapper users who would be affected by backwards-incompatible changes, so we would try our hardest to avoid them.

But it's important to know that the Sapper API barely exists - 90% of it is Svelte, and there are a few conventions, so it's hard to suggest that there will be huge changes between what it is now and 1.0.

The best thing to do is a bit of prototyping/experimentation to figure out if it fits your usecase, and if so, then use it. The same for any framework or technology choice.

[magnus-eriksson]

@antony It doesn't really matter if you've used it for two years without any issues. We have no idea how you're using it or for what. And as long as the documentation starts with "Sapper is in early development, and some things may change before we hit version 1.0.", it's a no-go for the vast majority of companies looking for something to build their long-term applications in.

If the developers of the framework can't commit to the current API (since they've put a warning in the docs), why should we? Most companies I've worked at, or worked with, wouldn't even consider it because of that and I understand and agree with them. Developers need to feel comfortable in the main tool their using or, if you ask me, it would be irresponsible to use it (from stakeholders perspective.)

If it is, as you say, stable and the API haven't changed in more than two years, then just make an official stable release. That would most likely mean more people would try it out as a real option.

The fixation on the version number comes from the docs, not by the community so there's no wonder people explicitly asks for version 1.0.

[pngwn]

To answer the question, there isn’t a roadmap right now and there aren’t any immediate plans to create one although it would be nice to come up with something in the medium term.

In terms of stability, the fact that it is pre-1.0 does mean that there could be breaking changes but in reality any changes are likely to minimally breaking although this obviously can’t be guaranteed.

Development has slowed a little on sapper over the past few months as many of the maintainers are busy irl and svelte core is the main priority. Hopefully we will get chance to come back to sapper shortly but again due to the fact that everyone is a volunteer and have jobs and lives, none of this can be guaranteed.

These probably aren’t the answers you’re looking for but this is the current situation.

[magnus-eriksson]

It might not be the answer I was hoping for, but it's a good and honest answer.
I completely understand and respect that life happens and priorities change.

Thanks for the clarification!

[benmccann]

We've added a question to the FAQ about version numbers: https://sapper.svelte.dev/faq#version-numbers

And #1429 for some information about future directions

[samal-rasmussen]

From the horses mouth:
https://www.youtube.com/watch?v=qSfdtmcZ4d0

Seems there will not be a Sapper version 1.0 ever. From what I understand of it Svelte itself will be built out to handle most of what Sapper does, only better because of Snowpack.

[ehrencrona]

It's important to understand, though, that there will be a migration path forward to the new solution. Migration will require effort but most of the codebase should survive; it shouldn't discourage anyone from using Sapper in the meantime.