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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge past and upcoming ymls #323

Conversation

amrabdelwahab
Copy link
Contributor

  • the main idea behind this pr is to avoid the unnecessary commits of moving upcoming conferences to past
  • I tried using where_exp but it got overly complicated so went with this simple approach
  • from now on the conference needs to be added once and then it should sit in the correct list
  • I added the key start_date to be used to identify event start

Let me know what do you think

* the main idea behind this pr is to avoid the unnecessary commits of moving upcoming conferences to past
* I tried using where_exp but it got overly complicated so went with this simple approach
* from now on the conference needs to be added once and then it should sit in the correct list
@matiaskorhonen
Copy link
Contributor

This gets a 👍 from me, I was thinking of submitting a PR like this myself.

What would you think of having both start_date and end_date as separate values and converting them to the range programatically? Something like this (as Ruby, the Liquid markup will need to be worked out):

if start_date.month == end_date.month
  "#{start_date.month} #{start_date.day}-#{end_date.day}, #{start_date.year}"
elsif start_date.year == end_date.year
  "#{start_date.month} #{start_date.day}-#{end_date.month} #{end_date.day}, #{start_date.year}"
else
  # This should only trigger if some crazy person has a conference over the New Year
  "#{start_date.month} #{start_date.day}, #{start_date.year}-#{end_date.month} #{end_date.day}, #{end_date.year}"
end

@amrabdelwahab
Copy link
Contributor Author

@matiaskorhonen I think it is a good idea, but maybe let's do it in a separate PR not to complicate the scope of this further? also I don't know what is happening in travis but somehow bundler is not available on the build machine anymore

@jonallured
Copy link
Member

This looks awesome, good idea!! I kicked off another build, but it's red too so I'll have to take a closer look at that. Otherwise, this is pretty close to merging IMO. 🎉

@amrabdelwahab
Copy link
Contributor Author

@jonallured So this comes from travis documentation:

On January 3rd 2019 the Bundler team released Bundler 2.0 which dropped support for Ruby versions 2.2 and older, and added a new dependency on RubyGems 3.0.0. A subsequent release, 2.0.1, requires RubyGems 2.5.0.

Under many configurations, Travis CI installs the Ruby runtime on the fly. This means installing the latest Bundler at run time, which may cause problems due to the unsatisfied requirements.

So I basically updated the gemfile lock to be bundled with bundler 2 and now it works seemlessly :)

@jonallured
Copy link
Member

cool! 😎

@jonallured jonallured merged commit e4eba69 into ruby-conferences:master Aug 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants