Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 1.8.2 #10522

Merged
merged 314 commits into from Nov 14, 2019
Merged

Release 1.8.2 #10522

merged 314 commits into from Nov 14, 2019

Conversation

@benjamn
Copy link
Member

@benjamn benjamn commented Apr 10, 2019

Meteor 1.8.1 has been released and recommended 馃帀 馃尞 馃挮, and (as always) the outstanding issues/features fall into two categories:

  • those we can fix/implement by releasing updates to Meteor packages (Package patches), and
  • those that will require a follow-up Meteor release, because they involve changes to the meteor/tools codebase (including the dev bundle), or because they involve significant changes to core packages that we want to avoid releasing until the next Meteor release.

Meteor 1.8.2 (this PR) will bundle up any urgent bug fixes or minor improvements that require a new Meteor release. Feel free to target the release-1.8.2 branch instead of devel with any PRs that seem to fit this description, or we can help you make that decision if you're unsure.

As anyone following Meteor development recently will realize, community input matters a LOT when it comes to deciding what goes into a release, and when it's time to stabilize/finalize it. We welcome that input, and we will do our best to release Meteor 1.8.2 as soon as it's clear it solves specific real problems for Meteor developers.

There will also soon be a Meteor 1.9 pull request for more experimental changes, such as (potentially, but not limited to) upgrading Node.js. Let us know if you think we've mistakenly put something into the 1.9 Milestone that belongs in 1.8.2, or vice-versa!

@benjamn benjamn added this to the Release 1.8.2 milestone Apr 10, 2019
@benjamn benjamn self-assigned this Apr 10, 2019
@benjamn benjamn changed the base branch from devel to master Apr 10, 2019
@rj-david
Copy link
Contributor

@rj-david rj-david commented Apr 12, 2019

Seems like the original issue was closed so I'm not sure if this is the right thread. For the recent release to fix the xcode and swift issues, are we keeping that release or are we expected to roll it to 1.8.2? I remember reading that it was just temporary so I am not sure if we should move all our projects now to that version or wait for 1.8.2 or should it automatically roll into 1.8.1 once the plugin is updated.

Loading

@benjamn
Copy link
Member Author

@benjamn benjamn commented Apr 12, 2019

@rj-david That release was just a way to test the cordova-plugin-meteor-webapp@1.7.0 changes before publishing a new version of webapp. I believe updating to webapp@1.7.4 will solve the problem now, unless there were other changes required within Meteor?

Loading

@benjamn benjamn force-pushed the release-1.8.2 branch 3 times, most recently from a3cdcd4 to 0482e66 Apr 26, 2019
@rj-david
Copy link
Contributor

@rj-david rj-david commented Apr 30, 2019

meteor update --release=1.8.2-beta.0

Getting this message
This project uses Meteor 1.8.2-beta.0, which isn't available on this platform. To work with this app on all supported platforms, use meteor update --release METEOR@1.8.1 to pin this app to the newest compatible release.

Using Ubuntu 18.10. Not an issue with the alpha versions

Loading

@benjamn
Copy link
Member Author

@benjamn benjamn commented May 2, 2019

@rj-david That should be fixed in the next beta release (coming today), thanks to #10542. 馃

Loading

@benjamn benjamn force-pushed the release-1.8.2 branch 4 times, most recently from 69af802 to b0a8e1b May 2, 2019
@brucejo75
Copy link
Contributor

@brucejo75 brucejo75 commented May 2, 2019

Hi @benjamn, I am seeing an interesting timing bug with v1.8.1, maybe it could be looked into for 1.8.2? This bug is happening for me in my Cordova build.

There is a very simple repro in #10157.

Loading

@benjamn
Copy link
Member Author

@benjamn benjamn commented May 2, 2019

@brucejo75 I'll put it in the 1.8.2 milestone, though I have to admit I don't have any prior expertise in this area, so I welcome anyone else to investigate further.

Loading

@brucejo75
Copy link
Contributor

@brucejo75 brucejo75 commented May 2, 2019

I will keep looking at it, it is interesting (and vexing!).

Loading

@rj-david
Copy link
Contributor

@rj-david rj-david commented May 3, 2019

@rj-david That should be fixed in the next beta release (coming today), thanks to #10542.

Confirming the fix.

For beta.1, got the following error: #10544

Loading

@brucejo75
Copy link
Contributor

@brucejo75 brucejo75 commented May 3, 2019

Hi @benjamn, I got a fix for #10157: #10543.

There is a build break that I do no know how to fix, maybe #10537 would help it?

Loading

@lamhieu-vk
Copy link
Contributor

@lamhieu-vk lamhieu-vk commented May 13, 2019

I updated the target of #10422 to this PR instead of devel branch, it's ok?

Loading

benjamn added 3 commits May 16, 2019
We ended up with two different versions of the reify package (0.19.0 and
0.19.1) in the last build of the dev bundle, which seems to have caused
the test failures.
@brucejo75
Copy link
Contributor

@brucejo75 brucejo75 commented May 17, 2019

Hi @benjamn , #10543 (fix for #10157) is ready to pull in. Do you have a plan to pull this in for a certain beta/rc?

Loading

benjamn added 9 commits Nov 12, 2019
Note that publishing 1.8.2-rc.8 failed on all platforms due to EMFILE (too
many open files) errors, which necessitated reverting PR #10771.
Falling back to a full recursive copy was MUCH more expensive than waiting
a short amount of time before retrying the rename.

This aligns with the way graceful-fs handles EPERM and EACCES errors on
Windows: https://www.npmjs.com/package/graceful-fs#improvements-over-fs-module
鈥ety.

Now that files.rename uses Promise.prototype.await on Windows, it's
important to be sure it never gets called outside of a Fiber. Though we
don't run our full test suite on Windows, we can validate this expectation
by wrapping files.rename on all platforms. This commit should be reverted
once the validation is complete.
鈥date safety."

This reverts commit 52d4809, as promised
in the previous commit message.
鈥ging-output

Fix mysterious Windows AppVeyor test stalls.
@benjamn
Copy link
Member Author

@benjamn benjamn commented Nov 13, 2019

Now that the little green checkmark has been restored, I fully expect this to be the last Meteor 1.8.2 release candidate:

meteor update --release 1.8.2-rc.10

Give it a try, especially if you're using Windows, since #10774 should greatly reduce the amount of recursive directory copying and deletion that Meteor has to do on Windows, in favor of simply renaming directories (something that should be simple and reliable鈥 but alas nothing is simple on Windows).

Loading

benjamn added 2 commits Nov 13, 2019
#10772 (comment)

The assertion in tools/fs/optimistic.ts was failing if I passed a relative
path for --test-app-path, and passing the path as a second argument when
calling assert made it easier to tell what was going on, so I decided to
keep that change.
@benjamn
Copy link
Member Author

@benjamn benjamn commented Nov 14, 2019

By the way, once we merge this PR into master and then merge master back into devel, we will continue progress towards Meteor 1.9 on the release-1.9 branch, but progress towards Meteor 1.8.3 (like merging all those TypeScript PRs 馃檶 and deduplicating jquery) will take place on the devel branch. In other words, there will be no release-1.8.3 branch, except perhaps for archival purposes after Meteor 1.8.3 has been released.

This idea was proposed to me by the Tiny team, since they (quite correctly) observed that the default branch for this repository (devel) appears totally dead right now, even though we're actively working on multiple release branches!

Loading

@benjamn benjamn merged commit d8563da into master Nov 14, 2019
20 checks passed
Loading
@arggh
Copy link
Contributor

@arggh arggh commented Nov 14, 2019

Congratulations! 馃帀

Loading

@xpressabhi
Copy link
Contributor

@xpressabhi xpressabhi commented Nov 17, 2019

meteor update is not updating my project to 1.8.2.
Do I need to run any other command?

Loading

@smeijer
Copy link

@smeijer smeijer commented Nov 17, 2019

@xpressabhi, I was running into the same issue. You can use the --release argument for the time being to force an update anyway.

meteor update --release 1.8.2

Loading

@arggh
Copy link
Contributor

@arggh arggh commented Nov 17, 2019

I was running into the same issue.

New Meteor releases are not immediately recommended, so update is working as intended and the --release flag is the way to go until 1.8.2 is recommended.

Loading

@smeijer
Copy link

@smeijer smeijer commented Nov 17, 2019

Now you mention that I remember it. But isn't that a bit weird? I mean, the release candidate is already being used as a guard for those last bugs.

Loading

@brucejo75
Copy link
Contributor

@brucejo75 brucejo75 commented Nov 17, 2019

@smeijer,

Now you mention that I remember it. But isn't that a bit weird? I mean, the release candidate is already being used as a guard for those last bugs.

I think the current release strategy makes good sense. It is a practical deployment strategy. And it is common practice among those that release software that users install on their own PCs.

  1. Hard core PR followers will maybe install the betas or release candidates.
  2. Once the version is released the word spreads to the next level of Meteor enthusiasts, e.g maybe those on the forums. We figure out how to install with --version.
  3. Finally, it becomes a recommended release and everyone is prompted to upgrade.

At each level you have more and more users. Sometimes something is found at step 2 and the major release is never recommended.

If you look at all the recommended releases you will see issues with 1.3.2 & 1.3.3. In the history you can spot a number of bugs on those releases soon after they were posted, but prior to being recommended.

Loading

@rj-david
Copy link
Contributor

@rj-david rj-david commented Nov 18, 2019

@benjamn, thanks for your hard work to push 1.8.2 out. Just read your updates above regarding the use of devel branch. What captures my attention was the planned 1.8.3 version for the remaining PR's. Happy to read that these PR's will be included.

Can you give some updates on the planned releases as we are actually preparing for testing 1.9.beta next after upgrading our projects to 1.8.2. Thanks

Loading

@benjamn
Copy link
Member Author

@benjamn benjamn commented Nov 18, 2019

Sometimes something is found at step 2 and the major release is never recommended.

Yep, that's definitely a nightmare scenario, but it has happened a few times before.

@rj-david We will keep merging devel into release-1.9 on a regular basis, so I think you can safely start using 1.9 without missing anything from 1.8.3. Of course, 1.9 may be less stable than 1.8 because it's still in beta, but I trust you already have the right expectations about that.

Loading

@sebakerckhof
Copy link
Contributor

@sebakerckhof sebakerckhof commented Nov 21, 2019

Regarding the new branching strategy: can we then bring back tags for a certain release, or it will be hard to find the code of a certain release without the release branches.

Loading

@CaptainN
Copy link
Contributor

@CaptainN CaptainN commented Nov 21, 2019

I imagine a release branch would be cut for each release? That's the standard git feature branch workflow.

Loading

@p3pp8
Copy link

@p3pp8 p3pp8 commented Nov 25, 2019

Sorry to bother you guys but i've this Cannot find module 鈥榬eify/lib/runtime鈥 error on built applications. Any idea? Thanx in advance!

Loading

@SimonSimCity
Copy link
Contributor

@SimonSimCity SimonSimCity commented Nov 26, 2019

@p3pp8 Is this only with the 1.8.2 release? 'Cause I have a similar problem - but already with the version 1.8.1: #10783 I solved it by adding the dependency manually to my packages.json file to get the build working on Linux, but then got an exception when running this app on Windows, which I've shown in detail. Might be good to create a new ticket for this issue anyways.

Loading

@p3pp8
Copy link

@p3pp8 p3pp8 commented Nov 26, 2019

@SimonSimCity Yes, only on 1.8.2. Anyway i've solved adding reify and @babel/parser in package.json then everything was working fine for me.

Loading

@Gywem
Copy link

@Gywem Gywem commented Jan 2, 2020

In a large project, I was able to see only the client refreshing as expected but my application was accessible only after web.browser.legacy was finished, is that expected? BTW this project is not using meteor.mainModule configuration on package.json.

@filipenevola I think the last part is important: if you're not using meteor.mainModule, then Meteor will likely decide that more of your modules seem to be involved in the server bundle, and thus a server restart will be triggered in more cases.

In other words, while there may be ways to improve this behavior in the future, the general advice is to try using meteor.mainModule to take control over the entry points for the various bundles. I don't think this issue needs to block Meteor 1.8.2, since the behavior was strictly worse in 1.8.1 (server restarts for anything not in the client/ directory).

I was able to include the meteor.mainModule configuration on such large project, which has improved the client and server module detection and it has had really great impact on this project. However, I still see the behavior that @filipenevola described. So, any client-only change is producing a client refresh, but until we get the web.browser.legacy bundle built, the app isn't available.

=> Client modified -- refreshing
=> Finished delayed build of web.browser.legacy in 21970ms

Should we track this problem in a different github issue?

Side note: I believe this #10824 will help a lot on our development process when merged 鉂わ笍

Loading

@kuttikrishnankodoth
Copy link

@kuttikrishnankodoth kuttikrishnankodoth commented Jul 24, 2020

Can someone tell me in plain english how to fix the source map debugging issue

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet