How to share local packages between Meteor versions?!

help
1

I’ve set-up a local folder where I store central packages I want to re-use across apps (using the PACKAGE_DIRS environment variable).

Two of my projects are still on Meteor 1.1, and I now wanted to create a new project from scratch using Meteor 1.2, to test out this new version.

However, I’ve run into a deadlock. One of my package.js files contains an asset, defined by the isAsset: true option. AFAIR, this is the only way to define assets in Meteor 1.1, so I have to keep it this way until all apps are on 1.2.

However, this prevents my new Meteor 1.2 app to start. Although this app doesn’t even include the package, it crashes with this error:

   While reading package from `/Users/waldgeist/Documents/Development/htdocs/packages/meteor/phantom`:
   package.js:52:7: The `isAsset` option to `addFiles` is deprecated. Use PackageAPI#addAssets instead.

It’s more than strange that a deprecated declaration prevents the whole startup. But what makes it even stranger is the fact that this package isn’t required by the app at all. Obviously, the fact that the package is located in the central package repository is enough to break everything. WTF?

Any ideas how to solve this? I cannot just use “addAssets”, since this would break the 1.1 apps that actually need the package. :-/

1 Like
2

One way to get around this if your apps are not all migrated is to do:

if (api.addAssets) {
  api.addAssets(...);
} else {
  api.addFiles(...);
}

I think it might be a good idea for us to do this for you in 1.2.1, and print a warning instead.

3

Filed the issue:

Hoping to release 1.2.1 next week, maybe on Wednesday.

2 Likes
4

@sashko: Thanks a lot for filing this, and also for the work-around. Obviously, I’m quite dumb not thinking of checking the existence of api.addAssets. I sometimes forget that’s all just JavaScript :smile: Ok, it’s already a little late here (10:30 p.m.). So goodnight from my side…

5

Hi @sashko - are you still planning to to release 1.2.1 tomorrow?

Thanks for some feedback
Tom

6

That’s the plan, unless something bad happens. My idea is to try to do releases on some sort of regular schedule so that it doesn’t take 5 months for someone’s bug fix to get released. 1 month isn’t ideal either, but it’s a start!

1 Like
7

Off-topic:

Ok, thanks. I am asking to plan some time also for updating the arm / universal fork. Since last 10 days, nearly 100 downloads were taken for that and I would like to have it mostly synced to official release.

Could you be so kind (if you have some few free time) to check and guide me on that issue: https://github.com/meteor/meteor/issues/5307#issuecomment-146846233

Thanks a lot
Tom

8

When some1 try to schedule releases it always remind me of our great example: Debian stable :smiley:

9

Is there a joke hidden in there somewhere? I don’t know much about Debian.

10

They have stable/unstable/experimental branches. And stable have ~2 years release cycle.
But it is good model for their usecase and really freezed production stable version.

1 Like
11

I am also an old / long Debianist :slight_smile: but those release cycles have to depend on the product.

If I am looking for a stable router OS with less changes and less issues - Debian stable is great!

If you are in need of using a number of updated software like mongo node mysql apache nginx … it is a pain. Most Debians on that path are mixing the repos like getting most from stable but injecting from testing.

So for those environments I prefer Ubuntu LTS with a long term support and a rolling release for good as stable software packages.

As an idea to you at MDG: 1.1.x is your stable branch and you just bring in some important fixes for time period of x-month.

1.2.x is your upcoming (stable) branch which is already production ready but maybe time consuming when updating (3rd party etc.) - This is a rolling release until stable marked and gets updates like monthly or on hot fixes

github devel is cutting edge and just for working with what is upcoming somedays.

I guess that those kind of release cycles may be welcomed in the community as well, as already mentioned in other words from @awatson1978 (clinical meteor)

Just my 2cents
Tom

12

@tomfreudenberg I think what you are saying is already true, we just haven’t written it down anywhere.

  • 1.3 will probably have major changes, but hopefully nothing on the scale of 1.2 - less or no breaking stuff.
  • 1.2.1 will have minor changes that really should cause 0 breaks, unless you were somehow depending on a bug being present in a weird way.

If there is a security issue, we always backport them to some number of previous releases. For example, right now it would probably cover 1.0, 1.1, and 1.2.

Anyway, I’ve filed an issue and created a milestone on GitHub for 1.2.1: https://github.com/meteor/meteor/issues/5478

13

@sashko great for documenting / pointing it here and on github.

Thanks
Tom

P.S.: To have Milestones aligned with the issues for upcoming releases is a great thing! Hopefully this is not a too time consuming task for you and you are able to continue that.

14

Unfortunately, they aren’t as helpful as they could be at the moment, since they don’t really tell you which issues will be fixed in future releases - they are just short term tasks to get the current release out. But it’s a good start!

15

Great news!!

The issue is fixed now and will be released in 1.2.1. Sorry for the pain in the meantime. https://github.com/meteor/meteor/issues/5458

1 Like
16

@sashko: Thanks for the fix, highly appreciated!