Finishing Original Deprications, New Deprications

4 views
Skip to first unread message

Eric B Merritt

unread,
Dec 10, 2011, 11:17:50 AM12/10/11
to erlwa...@googlegroups.com
Guys,

Some months ago we sent out a list of projects that we are deprecating
from Erlware. Within the next weeks we will be moving the following
projects out of Erlware.

crary
crary_dav
crary_dir_listing
erlang_expat
fconf
tercio

The will not disappear from the world. We will just find some new
obviously deprecated home for them.

There are also a number of projects that we will be moving through the
deprecation process as well.

erlware/ciconia
erlware/erlware
erlware/ecrypt
erlware/cryptographic
erlware/faxien
erlware/erlware-mode
erlware/ktuo
erlware/bootstrap
erlware/erlcron
erlware/portius
erlware/otp-base
erlware/uri
erlware/gen_socket
erlware/fconf
erlware/efcgi

These are ones that are, for the most part, already orphaned and lack
users. That is, there are no forks, no feedback, no users or there are
existing popular projects that fill the same need.

If you are using these projects or have an interest in maintaining them
this is your chance to step and become a maintainer for one of this
projects. Otherwise, the deprecation announcement will go to
erlware-questions at the end of next week.

Jordan Wilberding

unread,
Dec 10, 2011, 7:47:56 PM12/10/11
to erlwa...@googlegroups.com
crary, crary_dav, crary_dir_listing, erlang_expat, fconf, and tercio have all been transferred to https://github.com/erlware-deprecated

In a month, we will be moving the other projects listed below there as well.

Thanks!
JW


--
You received this message because you are subscribed to the Google Groups "erlware-dev" group.
To post to this group, send email to erlwa...@googlegroups.com.
To unsubscribe from this group, send email to erlware-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.


Stan McQueen

unread,
Dec 15, 2011, 8:19:42 PM12/15/11
to erlwa...@googlegroups.com
We're still using faxien, the original sinan, and portius in our
production environment.

Stan

Martin Logan

unread,
Dec 15, 2011, 11:56:53 PM12/15/11
to erlwa...@googlegroups.com, erlwa...@googlegroups.com
Cryptographic should not be deprecated

Sent from my iPod

Eric Merritt

unread,
Dec 19, 2011, 12:20:29 PM12/19/11
to erlwa...@googlegroups.com
On Thu, Dec 15, 2011 at 8:19 PM, Stan McQueen <stan.m...@gmail.com> wrote:
> We're still using faxien, the original sinan, and portius in our
> production environment.
>
> Stan

Stan,

As Jordan mentioned these are not going away. The are currently not
actively developed. This just makes that fact more obvious so that
people don't start using it for new projects. The code will continue
to be hosted on github indefinitely.

Just to reiterate, nothing is substantively changing. These projects
that are being depricated are already not being coded on. We are just
making that fact visible.

Eric

Eric Merritt

unread,
Dec 19, 2011, 12:20:44 PM12/19/11
to erlwa...@googlegroups.com
Are you going to maintain it?

Tristan Sloughter

unread,
Dec 16, 2011, 12:00:29 AM12/16/11
to erlwa...@googlegroups.com
I have to chime in that eCD is also still using those 3 in production. But that I hope to remove them from use within the next couple months... God willing.

I'm not entirely sure on how I plan to do this, but it will probably be first experimented with when I start deploying ClaimsTrade with Chef on Rackspace in the coming weeks.

So if anyone has ideas let me know. As of right now I may just be replacing any sort of dependency and package management (faxien/portius) with building self contained tarballs (including erts) and deploying those each time for an upgrade.

Tristan

Eric Merritt

unread,
Dec 19, 2011, 12:28:40 PM12/19/11
to erlwa...@googlegroups.com
On Fri, Dec 16, 2011 at 12:00 AM, Tristan Sloughter
<tristan....@gmail.com> wrote:
> I have to chime in that eCD is also still using those 3 in production. But
> that I hope to remove them from use within the next couple months... God
> willing.

Thats cool, as I said nothing at all is changing from the status quo.
We are just making the lack of maintenance obvious for the future. Its
a simple organizational move.

>
> I'm not entirely sure on how I plan to do this, but it will probably be
> first experimented with when I start deploying ClaimsTrade with Chef on
> Rackspace in the coming weeks.

I would suggest creating a release tarball and then just moving those
tarballs around using Chef. That actually should be pretty easy all
around.

> So if anyone has ideas let me know. As of right now I may just be replacing
> any sort of dependency and package management (faxien/portius) with building
> self contained tarballs (including erts) and deploying those each time for
> an upgrade.

lol, thats the way to go I think.

Reply all
Reply to author
Forward
0 new messages