Hey folks,

With the end of the year upon us, we've been paying extra attention to
thoughtbot's open source projects. I want to take a moment to sketch
out our tentative plans for Clearance and solicit your feedback.

Internally, we laid out our biggest problems with Clearance, and
prioritized them:

1) Remove email confirmation.

We have been removing email confirmation from almost all our apps that
use Clearance. On the apps where email confirmation was left in, we
noticed a number of user experience problems. I'll try to write a
comprehensive blog post explaining those problems as soon as I can.

These two reasons have convinced led us to decide that email
confirmation does not belong in Clearance. We've already removed the
code from master. The commit is here:

https://github.com/thoughtbot/clearance/commit/f8ec9a95cc81c0fe2c7eb9...

We're not sure of the best way to communicate to current and future
Clearance users who want to keep email confirmation in their apps. Do
you have any ideas?

2) Improve the test harness and take advantage of Bundler.

Clearance is behind the current standard flow of working with Ruby
open source libraries:

git clone && bundle install && rake

We've also been experimenting with better ways to test across Ruby
versions:

https://github.com/thoughtbot/appraisal

An important goal for us with Clearance is testability. Once we have
some improvements to the test suite in place, we'll feel better about
future changes to the library.

3) Remove 403::Forbidden

This is related to #1. Setting the 403 status code has turned out to
be an awful user experience in some browsers such as Chrome on Windows
machines. This is a relatively benign change that shouldn't affect
developers using Clearance in their apps but should result in a better
user experience for users of applications that use Clearance.

4) Remove deprecations

Many methods in the library were deprecated over a year or more. We're
going to finally remove those methods as the warning time has been
ample.

-----------------------------------------

Once we complete #1, #2, #3, and #4, we will probably release
Clearance 1.0. We feel the removal of the email confirmations is a big
enough API change to warrant it.

After 1.0 is released, we have some ideas for 1.1. They include:

* Removing dependency on default_url_options. This has been a major
cause of problems according to reports in Github Issues. This should
be an easy and benign change.
* Removing the views generator. With email confirmation gone, the
views are pretty simple. The only tricky form is the password reset.
We have a formatastic generator that seems like overkill and there are
open patches for a Haml generator that we're concerned we'd be bad
about maintaining since we don't use Haml. Does anyone have ideas
here? This is feeling like a "good documentation" task rather than a
"generators which need to be well-tested and maintained" task to me.
* Removing password confirmation. Controversial and we've barely
talked about it but while we're streamlining, we should talk about it.

Depending on how those go, we have some ideas for later releases,
version numbers pending, but maybe 2.0. They include:

* Switching to BCrypt. The Ruby community seems headed that way, for
seemingly good reasons, and we're happy to follow their lead.
* Making Clearance::User database-agnostic. We've used it on Mongo
apps and it wasn't bad to alter it outside the library so it might
make sense to formalize it in the library.
* Use Rack for session/cookie storage. This is also the direction
libraries like Devise/Warden are going. From a code purity standpoint,
we like this idea but in practice it hasn't really been an issue so
has always been low priority. I don't think we're interested in adding
a Warden dependency to Clearance but looking for feedback here as
well.

We recognize Clearance is a very opinionated library that won't meet
everyone's needs but that's okay in an environment with other options
like Devise, Authlogic, and Restful Authentication. We want to have a
simple, small, well-tested, and useful authentication library that
fits most of our goals across the 30 or so Rails apps we work on every
year. If we hit those goals, we feel others will benefit as well.
That's been true in the library's life so far and we hope that will
continue.

Let us know what you think.

Thanks,
Dan

On 22 December 2010 19:07, Dan Croak <dcr...@thoughtbot.com> wrote:

I am not sure why this is necessary but your email blog post will explain
the same, I hope.

I would suggest creating another gem called "clearance_extension" or
something similar (which is what Rails 3 did when it took out
form.error_messages). This gem could hold all the functionality that is not
part of the main clearance gem for example: email confirmation bit. If a
user wants to keep the email_confirmation bit then they need to install this
gem. I know this will create a responsibility of maintaining an additional
gem, but I would like to put my name forward for creating and maintaining it
should thoughtbot decide to go down this route. Anyway, I will have a go at
it.

It's been overdue and I would like to see how bundler can be used for
development in a Rails Engine. I tried few experiments of using bundler for
developing a Rails engine and then in the test rails app and for some reason
or other it would just error out. I looked at Spree's code and it took me
ages to get bundler set up with it and just felt wrong. It could be me but
it was just convoluted.

Yes.

Sure.

Makes sense.

* Removing the views generator. With email confirmation gone, the

All these things that are on the borderline and do not fit the current
thoughtbot workflow can all go into clearance_extension gem. This would
really move the noise out of clearance and leave it with core functionality
to deal with. If for some reason, a need arises (or you feel) to bring some
functionality in the clearance_extension into the clearance gem, then it can
be moved and made part of the core.

I think I created this issue based on some suggestion in the ML.

* Making Clearance::User database-agnostic. We've used it on Mongo

That would be amazing.

* Use Rack for session/cookie storage. This is also the direction

I think if you don't feel the need for it, don't do it. Let the requirements
and the community opinion drive the clearance development.

We recognize Clearance is a very opinionated library that won't meet

clearance_extension gem solves this problem as well as it will allow users
to add new functionalities and at the same time keep the clearance core
clean. However, this will have to be controlled in some fashion otherwise
this can get out of hands easily and I am more than willing to manage it.

I am for one is quite relieved because clearance repository has been quite
for a while with not much going on and I am looking forward to the
amendments and modifications.

Please give your feedback on my thoughts.

Anuj

--
Anuj DUTTA