> It's less than 12 hours to Mongoid 3.0 is due, but it depends on the
> unreleased MongoDB 2.2.  Looking at the MongoDB Jira issue tracker
> there are about 150 open issues marked for 2.2, it therefore seems
> unlikely that it will be released at or close to the Mongoid 3.0
> release time. Please let me know if there is a recommended upgrade
> procedure to Mongoid 3.0, and if there are any configuration choices
> in Mongoid 2.4-stable that reduce the number of breaking changes in
> the upgrade.

> There are several breaking changes in Mongoid 3.0, so when it's
> released I'd producing new applications in this version instead of
> 2.4-stable. However, our databases are hosted by MongoHQ so this may
> not be an option.

> Please let me know how you recommend upgrading to Mongoid 3.0, and if
> there are some configuration options in 2.4-stable that minimize the
> number of breaking changes in the upgrade.

> Thank you in advance for you assistance.

> Best,
> Andy

On Sun, Apr 8, 2012 at 2:50 PM, Durran Jordan <dur...@gmail.com> wrote:
> I'm going to push that deadline back since I still have some open issues
> left for 3.0 to flush out first. I've had all our Mongoid apps on master for
> a while to make sure all the changes there are still good, and just moved
> them over to the moped-integration branch before I merge that in and want to
> give them at least a week of hammering on it before shipping.

> As for the upgrade, I think it should be fairly simple. I have tried with
> every backwards incompatible change to have Mongoid raise a specific error
> when the old syntax is used, and give you instructions on how to change
> it... An example will be with changes in the index syntax - you'll get an
> error like this:

> -----
>      Mongoid::Errors::InvalidIndex:

>        Problem:
>          Invalid index specification on Person: age
>        Summary:
>          Indexes in Mongoid are defined as a hash of field name and
> direction/2d pairs,
>          with an :options hash for any additional options.
>        Resolution:
>          Ensure that the index conforms to the correct syntax and has the
> correct options.

>         Valid options are:
>           background: true|false
>           drop_dups: true|false
>           name: 'index_name'
>           sparse: true|false
>           unique: true|false

>         Valid types are: 1, -1, '2d'

>         Example:
>           class Band
>             include Mongoid::Document
>             index name: 1, label: -1, options: { sparse: true }
>             index location: '2d', options: { background: true }
>           end
> ----

> All error messages in Mongoid 3 follow this format. You get a general
> message indicating the problem, a summary which details why it happened, and
> a resolution with what you need to do to address it with example code. You
> can get an idea of how detailed these are now here:
> https://github.com/mongoid/mongoid/blob/master/lib/config/locales/en.yml

> I'm hoping that's all it takes - just do what the exceptions tell you and I
> expect the upgrade to be quick and easy, as from here on out I am treating
> exceptions at the framework level as documentation, not just simple errors.
> There will be a simultaneous release of the new docs, which are much more in
> depth, and I've been really good on keeping the CHANGELOG up to date with
> all the changes that you might encounter as well, with code examples there:
> https://github.com/mongoid/mongoid/blob/master/CHANGELOG.md

> None of the backwards incompatible changes will force a data migration or
> hinder any sort of compatibility with MongoHQ. The MongoHQ team graciously
> donated several databases with different configs to make sure that Mongoid
> is completely compatible and we have no hiccups - and I've got automated
> tests around all configurations, single-server, replica sets, and shards. 1
> of our production apps is on Mongoid master pointed at a MongoHQ replica
> set, the others we have on different rackspace configurations running MRI
> and JRuby to make sure everything is covered.

> Once the moped-integration branch goes into master, I'll post an update here
> as that's the final stretch. I've been working all this holiday weekend to
> get this all done, but I don't want to rush it if it's not finished... So I
> expect at least another week.

> 2012/4/8 Andreas Saebjoernsen <andr...@digitalplaywright.com>

>> It's less than 12 hours to Mongoid 3.0 is due, but it depends on the
>> unreleased MongoDB 2.2.  Looking at the MongoDB Jira issue tracker
>> there are about 150 open issues marked for 2.2, it therefore seems
>> unlikely that it will be released at or close to the Mongoid 3.0
>> release time. Please let me know if there is a recommended upgrade
>> procedure to Mongoid 3.0, and if there are any configuration choices
>> in Mongoid 2.4-stable that reduce the number of breaking changes in
>> the upgrade.

>> There are several breaking changes in Mongoid 3.0, so when it's
>> released I'd producing new applications in this version instead of
>> 2.4-stable. However, our databases are hosted by MongoHQ so this may
>> not be an option.

>> Please let me know how you recommend upgrading to Mongoid 3.0, and if
>> there are some configuration options in 2.4-stable that minimize the
>> number of breaking changes in the upgrade.

>> Thank you in advance for you assistance.

>> Best,
>> Andy

> Hi Durran,

> Thank you for the quick reply and clarification. I prefer strict
> consistency, so I'd like to migrate if the new version persists in a
> different way from the old, even if it is not necessary. Doesn't 3.0
> for instance improve precision when persisting time?

> Best,
> Andreas

> On Sun, Apr 8, 2012 at 2:50 PM, Durran Jordan <dur...@gmail.com> wrote:
> > I'm going to push that deadline back since I still have some open issues
> > left for 3.0 to flush out first. I've had all our Mongoid apps on master
> for
> > a while to make sure all the changes there are still good, and just moved
> > them over to the moped-integration branch before I merge that in and
> want to
> > give them at least a week of hammering on it before shipping.

> > As for the upgrade, I think it should be fairly simple. I have tried with
> > every backwards incompatible change to have Mongoid raise a specific
> error
> > when the old syntax is used, and give you instructions on how to change
> > it... An example will be with changes in the index syntax - you'll get an
> > error like this:

> > -----
> >      Mongoid::Errors::InvalidIndex:

> >        Problem:
> >          Invalid index specification on Person: age
> >        Summary:
> >          Indexes in Mongoid are defined as a hash of field name and
> > direction/2d pairs,
> >          with an :options hash for any additional options.
> >        Resolution:
> >          Ensure that the index conforms to the correct syntax and has the
> > correct options.

> >         Valid options are:
> >           background: true|false
> >           drop_dups: true|false
> >           name: 'index_name'
> >           sparse: true|false
> >           unique: true|false

> >         Valid types are: 1, -1, '2d'

> >         Example:
> >           class Band
> >             include Mongoid::Document
> >             index name: 1, label: -1, options: { sparse: true }
> >             index location: '2d', options: { background: true }
> >           end
> > ----

> > All error messages in Mongoid 3 follow this format. You get a general
> > message indicating the problem, a summary which details why it happened,
> and
> > a resolution with what you need to do to address it with example code.
> You
> > can get an idea of how detailed these are now here:
> > https://github.com/mongoid/mongoid/blob/master/lib/config/locales/en.yml

> > I'm hoping that's all it takes - just do what the exceptions tell you
> and I
> > expect the upgrade to be quick and easy, as from here on out I am
> treating
> > exceptions at the framework level as documentation, not just simple
> errors.
> > There will be a simultaneous release of the new docs, which are much
> more in
> > depth, and I've been really good on keeping the CHANGELOG up to date with
> > all the changes that you might encounter as well, with code examples
> there:
> > https://github.com/mongoid/mongoid/blob/master/CHANGELOG.md

> > None of the backwards incompatible changes will force a data migration or
> > hinder any sort of compatibility with MongoHQ. The MongoHQ team
> graciously
> > donated several databases with different configs to make sure that
> Mongoid
> > is completely compatible and we have no hiccups - and I've got automated
> > tests around all configurations, single-server, replica sets, and
> shards. 1
> > of our production apps is on Mongoid master pointed at a MongoHQ replica
> > set, the others we have on different rackspace configurations running MRI
> > and JRuby to make sure everything is covered.

> > Once the moped-integration branch goes into master, I'll post an update
> here
> > as that's the final stretch. I've been working all this holiday weekend
> to
> > get this all done, but I don't want to rush it if it's not finished...
> So I
> > expect at least another week.

> > 2012/4/8 Andreas Saebjoernsen <andr...@digitalplaywright.com>

> >> It's less than 12 hours to Mongoid 3.0 is due, but it depends on the
> >> unreleased MongoDB 2.2.  Looking at the MongoDB Jira issue tracker
> >> there are about 150 open issues marked for 2.2, it therefore seems
> >> unlikely that it will be released at or close to the Mongoid 3.0
> >> release time. Please let me know if there is a recommended upgrade
> >> procedure to Mongoid 3.0, and if there are any configuration choices
> >> in Mongoid 2.4-stable that reduce the number of breaking changes in
> >> the upgrade.

> >> There are several breaking changes in Mongoid 3.0, so when it's
> >> released I'd producing new applications in this version instead of
> >> 2.4-stable. However, our databases are hosted by MongoHQ so this may
> >> not be an option.

> >> Please let me know how you recommend upgrading to Mongoid 3.0, and if
> >> there are some configuration options in 2.4-stable that minimize the
> >> number of breaking changes in the upgrade.

> >> Thank you in advance for you assistance.

> >> Best,
> >> Andy

On Mon, Apr 9, 2012 at 11:30 PM, Durran Jordan <dur...@gmail.com> wrote:
> 3.0 no longer strips any precision off time, but it wont affect anything
> that was already persisted with the milliseconds stripped previously. But
> I'll make a note on the website upgrade section on the best way to migrate
> that if you desire to.

> 2012/4/10 Andreas Saebjoernsen <andr...@digitalplaywright.com>

>> Hi Durran,

>> Thank you for the quick reply and clarification. I prefer strict
>> consistency, so I'd like to migrate if the new version persists in a
>> different way from the old, even if it is not necessary. Doesn't 3.0
>> for instance improve precision when persisting time?

>> Best,
>> Andreas

>> On Sun, Apr 8, 2012 at 2:50 PM, Durran Jordan <dur...@gmail.com> wrote:
>> > I'm going to push that deadline back since I still have some open issues
>> > left for 3.0 to flush out first. I've had all our Mongoid apps on master
>> > for
>> > a while to make sure all the changes there are still good, and just
>> > moved
>> > them over to the moped-integration branch before I merge that in and
>> > want to
>> > give them at least a week of hammering on it before shipping.

>> > As for the upgrade, I think it should be fairly simple. I have tried
>> > with
>> > every backwards incompatible change to have Mongoid raise a specific
>> > error
>> > when the old syntax is used, and give you instructions on how to change
>> > it... An example will be with changes in the index syntax - you'll get
>> > an
>> > error like this:

>> > -----
>> >      Mongoid::Errors::InvalidIndex:

>> >        Problem:
>> >          Invalid index specification on Person: age
>> >        Summary:
>> >          Indexes in Mongoid are defined as a hash of field name and
>> > direction/2d pairs,
>> >          with an :options hash for any additional options.
>> >        Resolution:
>> >          Ensure that the index conforms to the correct syntax and has
>> > the
>> > correct options.

>> >         Valid options are:
>> >           background: true|false
>> >           drop_dups: true|false
>> >           name: 'index_name'
>> >           sparse: true|false
>> >           unique: true|false

>> >         Valid types are: 1, -1, '2d'

>> >         Example:
>> >           class Band
>> >             include Mongoid::Document
>> >             index name: 1, label: -1, options: { sparse: true }
>> >             index location: '2d', options: { background: true }
>> >           end
>> > ----

>> > All error messages in Mongoid 3 follow this format. You get a general
>> > message indicating the problem, a summary which details why it happened,
>> > and
>> > a resolution with what you need to do to address it with example code.
>> > You
>> > can get an idea of how detailed these are now here:
>> > https://github.com/mongoid/mongoid/blob/master/lib/config/locales/en.yml

>> > I'm hoping that's all it takes - just do what the exceptions tell you
>> > and I
>> > expect the upgrade to be quick and easy, as from here on out I am
>> > treating
>> > exceptions at the framework level as documentation, not just simple
>> > errors.
>> > There will be a simultaneous release of the new docs, which are much
>> > more in
>> > depth, and I've been really good on keeping the CHANGELOG up to date
>> > with
>> > all the changes that you might encounter as well, with code examples
>> > there:
>> > https://github.com/mongoid/mongoid/blob/master/CHANGELOG.md

>> > None of the backwards incompatible changes will force a data migration
>> > or
>> > hinder any sort of compatibility with MongoHQ. The MongoHQ team
>> > graciously
>> > donated several databases with different configs to make sure that
>> > Mongoid
>> > is completely compatible and we have no hiccups - and I've got automated
>> > tests around all configurations, single-server, replica sets, and
>> > shards. 1
>> > of our production apps is on Mongoid master pointed at a MongoHQ replica
>> > set, the others we have on different rackspace configurations running
>> > MRI
>> > and JRuby to make sure everything is covered.

>> > Once the moped-integration branch goes into master, I'll post an update
>> > here
>> > as that's the final stretch. I've been working all this holiday weekend
>> > to
>> > get this all done, but I don't want to rush it if it's not finished...
>> > So I
>> > expect at least another week.

>> > 2012/4/8 Andreas Saebjoernsen <andr...@digitalplaywright.com>

>> >> It's less than 12 hours to Mongoid 3.0 is due, but it depends on the
>> >> unreleased MongoDB 2.2.  Looking at the MongoDB Jira issue tracker
>> >> there are about 150 open issues marked for 2.2, it therefore seems
>> >> unlikely that it will be released at or close to the Mongoid 3.0
>> >> release time. Please let me know if there is a recommended upgrade
>> >> procedure to Mongoid 3.0, and if there are any configuration choices
>> >> in Mongoid 2.4-stable that reduce the number of breaking changes in
>> >> the upgrade.

>> >> There are several breaking changes in Mongoid 3.0, so when it's
>> >> released I'd producing new applications in this version instead of
>> >> 2.4-stable. However, our databases are hosted by MongoHQ so this may
>> >> not be an option.

>> >> Please let me know how you recommend upgrading to Mongoid 3.0, and if
>> >> there are some configuration options in 2.4-stable that minimize the
>> >> number of breaking changes in the upgrade.

>> >> Thank you in advance for you assistance.

>> >> Best,
>> >> Andy

> Durran,

> I'm starting a new project and I would like to use Mongoid 3.0, but I have
> to stick with the latest stable release here at work. Do you think the new
> gem and website/documentation will be released until next week or should I
> stick with 2.4.8?

> Thanks in advance!

> Mauricio Almeida
> @brandnewcode

On Thu, Apr 12, 2012 at 11:04, Durran Jordan <dur...@gmail.com> wrote:
> I'm currently shooting for Monday the 23rd, most notably because I have
> the 23rd - 31st off for vacation and can be available full-time for support
> that week. And gives me 11 more days to get the documentation and remaining
> issues finished.

> 2012/4/12 Mauricio Almeida <mauriciom...@gmail.com>

>> Durran,

>> I'm starting a new project and I would like to use Mongoid 3.0, but I
>> have to stick with the latest stable release here at work. Do you think the
>> new gem and website/documentation will be released until next week or
>> should I stick with 2.4.8?

>> Thanks in advance!

>> Mauricio Almeida
>> @brandnewcode

On Sunday, April 8, 2012 10:06:39 PM UTC+3, Andy S wrote:

> It's less than 12 hours to Mongoid 3.0 is due, but it depends on the
> unreleased MongoDB 2.2.  Looking at the MongoDB Jira issue tracker
> there are about 150 open issues marked for 2.2, it therefore seems
> unlikely that it will be released at or close to the Mongoid 3.0
> release time. Please let me know if there is a recommended upgrade
> procedure to Mongoid 3.0, and if there are any configuration choices
> in Mongoid 2.4-stable that reduce the number of breaking changes in
> the upgrade.

> There are several breaking changes in Mongoid 3.0, so when it's
> released I'd producing new applications in this version instead of
> 2.4-stable. However, our databases are hosted by MongoHQ so this may
> not be an option.

> Please let me know how you recommend upgrading to Mongoid 3.0, and if
> there are some configuration options in 2.4-stable that minimize the
> number of breaking changes in the upgrade.

> Thank you in advance for you assistance.

> Best,
> Andy

On Sunday, April 8, 2012 10:06:39 PM UTC+3, Andy S wrote:

> It's less than 12 hours to Mongoid 3.0 is due, but it depends on the
> unreleased MongoDB 2.2.  Looking at the MongoDB Jira issue tracker
> there are about 150 open issues marked for 2.2, it therefore seems
> unlikely that it will be released at or close to the Mongoid 3.0
> release time. Please let me know if there is a recommended upgrade
> procedure to Mongoid 3.0, and if there are any configuration choices
> in Mongoid 2.4-stable that reduce the number of breaking changes in
> the upgrade.

> There are several breaking changes in Mongoid 3.0, so when it's
> released I'd producing new applications in this version instead of
> 2.4-stable. However, our databases are hosted by MongoHQ so this may
> not be an option.

> Please let me know how you recommend upgrading to Mongoid 3.0, and if
> there are some configuration options in 2.4-stable that minimize the
> number of breaking changes in the upgrade.

> Thank you in advance for you assistance.

> Best,
> Andy

> Durran, when are you planning to release V 3.0? I'm planning a new release
> of my project and want to try the new version.

> Thanks

> On Sunday, April 8, 2012 10:06:39 PM UTC+3, Andy S wrote:

>> It's less than 12 hours to Mongoid 3.0 is due, but it depends on the
>> unreleased MongoDB 2.2.  Looking at the MongoDB Jira issue tracker
>> there are about 150 open issues marked for 2.2, it therefore seems
>> unlikely that it will be released at or close to the Mongoid 3.0
>> release time. Please let me know if there is a recommended upgrade
>> procedure to Mongoid 3.0, and if there are any configuration choices
>> in Mongoid 2.4-stable that reduce the number of breaking changes in
>> the upgrade.

>> There are several breaking changes in Mongoid 3.0, so when it's
>> released I'd producing new applications in this version instead of
>> 2.4-stable. However, our databases are hosted by MongoHQ so this may
>> not be an option.

>> Please let me know how you recommend upgrading to Mongoid 3.0, and if
>> there are some configuration options in 2.4-stable that minimize the
>> number of breaking changes in the upgrade.

>> Thank you in advance for you assistance.

>> Best,
>> Andy

> On Sunday, April 8, 2012 10:06:39 PM UTC+3, Andy S wrote:

>> It's less than 12 hours to Mongoid 3.0 is due, but it depends on the
>> unreleased MongoDB 2.2.  Looking at the MongoDB Jira issue tracker
>> there are about 150 open issues marked for 2.2, it therefore seems
>> unlikely that it will be released at or close to the Mongoid 3.0
>> release time. Please let me know if there is a recommended upgrade
>> procedure to Mongoid 3.0, and if there are any configuration choices
>> in Mongoid 2.4-stable that reduce the number of breaking changes in
>> the upgrade.

>> There are several breaking changes in Mongoid 3.0, so when it's
>> released I'd producing new applications in this version instead of
>> 2.4-stable. However, our databases are hosted by MongoHQ so this may
>> not be an option.

>> Please let me know how you recommend upgrading to Mongoid 3.0, and if
>> there are some configuration options in 2.4-stable that minimize the
>> number of breaking changes in the upgrade.

>> Thank you in advance for you assistance.

>> Best,
>> Andy