Spree 3.0 stable!

[dsadaka]

Greetings.

I see there is a spree 3-0-stable branch now.  This is great news.

However, the README does not include any installation instructions.  Also there are no release notes yet at https://guides.spreecommerce.com/

Are we to assume that the docs at https://guides.spreecommerce.com/ are to be followed for the 3.0 version as well?  If not, any idea when the new doc will be available?

Thanks,
Dan

[Jason Fleetwood-Boldt]

I believe we are right on the cusp of the actual release. 

----

Jason Fleetwood-Boldt

te...@datatravels.com

http://www.jasonfleetwoodboldt.com/writing

[Peter Berkenbosch]

Yes, there will be more real soon!

--

Peter Berkenbosch
Spree Commerce, Inc.

[dsadaka]

Thanks, Peter.  Any chance of "Very soon" being by next Monday? :)

Thanks again,
Dan

[Jeff Dutil]

It's not in the navigation yet I missed that part, but you can view the working draft here:

https://guides.spreecommerce.com/release_notes/spree_3_0_0.html

Feel free to submit a PR adding the link to the guides or adding any other useful gotchas you may run into.

[dsadaka]

Jeff,

thanks for the release notes.  Can you please point me to the new installation procedure?  Using the existing steps (spree_cmd, etc.) I am still getting 2.4. 

Thanks!
Dan

[Jeff Dutil]

I believe you would need to do spree _3.0.0.rc1_ install to get the pre-release version.

I'll see about updating the readme, but you can also just set to either the new version explicitly or set the branch to 3-0-stable in your Gemfile.  

Then run: bundle exec rails g spree:install

[Brendan Murtagh]

I just did this last night going from 2-4-stable to 3-0-stable via Github . I ran into an issue with ssl_allowed in better_spree_paypal_express so I currently have that commented out from my Gemfile.

Basically, I need to update Rails from 4.1.8 to 4.2.0, jquery-rails to ~> 4.0.3, spree_auth_devise to 3-0-stable branch, and to play it safe, both spree_gateway and spree_tax_cloud to their master branches.

I did a bundle install locally, added my Gemfile & Gemfile.lock to my repo and pushed to Heroku. I did not do a bundle exec rails g spree:install

However, on a deploy, I'm getting warnings that I'm still researching even though I've ran the suggested migrations in the message:

remote:        [Spree WARNING] Missing migrations.
remote:        [Spree WARNING] add_code_to_spree_promotion_categories from spree is missing.
remote:        [Spree WARNING] add_kind_to_zone from spree is missing.
remote:        [Spree WARNING] add_resellable_to_return_items from spree is missing.
remote:        [Spree WARNING] remove_environment_from_payment_method from spree is missing.
remote:        [Spree WARNING] remove_environment_from_tracker from spree is missing.
remote:        [Spree WARNING] remove_extra_products_slug_index from spree is missing.
remote:        [Spree WARNING] remove_spree_configurations from spree is missing.
remote:        [Spree WARNING] remove_token_permissions_table from spree is missing.
remote:        [Spree WARNING] rename_identifier_to_number_for_payment from spree is missing.
remote:        [Spree WARNING] update_product_slug_index from spree is missing.
remote:        [Spree WARNING] Run `bundle exec rake railties:install:migrations` to get them.

[Jeff Dutil]

The ssl controller concern was removed in Spree 3 in favor of Rails ForceSSL so you can remove that from better_spree_paypal_express, and you should turn config.force_ssl = true on for your production environment.  I'll add this to the release notes as well.

[Brendan Murtagh]

Sounds good. Thanks for the heads up & including it in the Release Notes.

-Brendan

Sent from my iPhone

[Jason Fleetwood-Boldt]

config.force_ssl = true will make all requests at all times be switched over to SSL. Is this recommended as a best practice? Historically in e-Ccommerce you stay on non-SSL pages until you checkout, log in, or otherwise get to an area of the app where you will be providing sensitive data.

I realize that security concerns are evolving with the high-profile attacks, is this recommendation an evolution because of that? I just wanted to know what the thinking was here because (historically) the industry best practice is to only switch the user to SSL when they get to a point where they start providing sensitive information.

-Jason

[Jeff Dutil]

It is best practice for any web application in 2015.  Fun fact it will also boost your SEO http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html 

You can just use force_ssl at the controller level if you would like to only use ssl for sensitive pages still though.

[Brendan Murtagh]

Just to follow this particular issue, I created PR #151 to remove ssl_allowed from the controller.

On Saturday, February 14, 2015 at 12:47:24 PM UTC-5, Brendan Murtagh wrote:

[Jason Fleetwood-Boldt]

Got it, thanks for the clarification. 

Yes I realize many people are moving to all-SSL all-the-time. So this change goes along with that trend.

-Jason