3 ms·

I use Mailcatcher for almost ten years now and never had a problem with it. Maybe is doesn't need maintenance?

gregoriol 2y ago
Same for Mailhog
iruoy 2y ago
There's no rush to move away from MailCatcher or MailHog, but if you're not using those solutions already I see no reason to use them over the maintained options.
- diggan 2y ago
  > I see no reason to use them over the maintained options Things that don't change over a longer time period can be more comfortable sometimes. Especially things you use often and build up a sort of "muscle memory" about.
  - rnewme 2y ago
    You ignored first part of that sentence.
    - naniwaduni 2y ago
      "Not changing" has value in its own right.
      - fiddlerwoaroof 2y ago
        Yeah, people underestimate the value of “finished” software: in an ecosystem with lots of stable dependencies, there’s very little reason for useful software to change constantly.
        picohik 2y ago
        Even "finished" software needs maintenance. Nothing is ever bug-free so needs fixes. And it doesn't live in a vacuum, the ecosystem evolves and continuous adjustments are needed when APIs evolve or libraries change. In well-written software, the maintenance burden is low, but it's not zero. Without any maintenance, you can maybe run some piece of software in some closed-off container for a while, but it will keep rotting away and eventually you won't even be able to compile it anymore.
        diggan 2y ago
        > Even "finished" software needs maintenance. What about "GNU Hello", never finished? Clearly this isn't true for 100% of all software, so the only thing we can conclude is that it either "depends" and/or is very subjective. > when APIs evolve or libraries change. If you live/work inside an ecosystem that favor stability over "evolving APIs", you can actually be able to use libraries that are decades old, that doesn't have any bugs for the stuff they expose and things just work. I mostly experience this in the Clojure ecosystem, but I'm sure it's true for other ecosystems too.
        e12e 2y ago
        >> What about "GNU Hello", never finished? Most recently removing an outdated dependency? > 2024-07-02 18:04:21 -0700 > maint: remove the obsolete gettext module https://git.savannah.gnu.org/cgit/hello.git/commit/?id=24225d705684322f482135e8a2d679485fce0811 https://git.savannah.gnu.org/cgit/hello.git/commit/?id=24225...
        picohik 2y ago
        > be able to use libraries that are decades old, that doesn't have any bugs for the stuff they expose and things just work. Acknowledging that all software has bugs is the first step to be able to produce high quality. > I mostly experience this in the Clojure ecosystem, but I'm sure it's true for other ecosystems too. How many decades exactly has your clojure existed without any bugs?
        account42 2y ago
      - sureIy 2y ago
        Yes, you definitely don't want to risk closing up all those holes discovered in the last 10 years, lots of people might be left out of your servers.
Widdershin 2y ago
Try add it to the Gemfile of a modern Rails project, the dependencies are very out of date and it won’t install.
- sj26 2y ago
  It's not designed to go in your Gemfile gem install mailcatcher :-)
- snackernews 2y ago
  Docs say > Please don't put mailcatcher into your Gemfile. It will conflict with your applications gems at some point.
  - NewJazz 2y ago
    Commenter was just making the fair point that the dependencies are out of date. Maintenance doesn't always mean UI redesigns or non-compatible config changes. Sometimes it is just fixing bugs and updating or replacing old dependencies.
- bdcravens 2y ago
  I always run Mailcatcher as a standalone Docker image (I'm already using Docker Compose for development), with no issues.

Same for Mailhog

There's no rush to move away from MailCatcher or MailHog, but if you're not using those solutions already I see no reason to use them over the maintained options.

diggan 2y ago
> I see no reason to use them over the maintained options Things that don't change over a longer time period can be more comfortable sometimes. Especially things you use often and build up a sort of "muscle memory" about.
- rnewme 2y ago
  You ignored first part of that sentence.
  - naniwaduni 2y ago
    "Not changing" has value in its own right.
    - fiddlerwoaroof 2y ago
      Yeah, people underestimate the value of “finished” software: in an ecosystem with lots of stable dependencies, there’s very little reason for useful software to change constantly.
      - picohik 2y ago
        Even "finished" software needs maintenance. Nothing is ever bug-free so needs fixes. And it doesn't live in a vacuum, the ecosystem evolves and continuous adjustments are needed when APIs evolve or libraries change. In well-written software, the maintenance burden is low, but it's not zero. Without any maintenance, you can maybe run some piece of software in some closed-off container for a while, but it will keep rotting away and eventually you won't even be able to compile it anymore.
        diggan 2y ago
        > Even "finished" software needs maintenance. What about "GNU Hello", never finished? Clearly this isn't true for 100% of all software, so the only thing we can conclude is that it either "depends" and/or is very subjective. > when APIs evolve or libraries change. If you live/work inside an ecosystem that favor stability over "evolving APIs", you can actually be able to use libraries that are decades old, that doesn't have any bugs for the stuff they expose and things just work. I mostly experience this in the Clojure ecosystem, but I'm sure it's true for other ecosystems too.
        e12e 2y ago
        >> What about "GNU Hello", never finished? Most recently removing an outdated dependency? > 2024-07-02 18:04:21 -0700 > maint: remove the obsolete gettext module https://git.savannah.gnu.org/cgit/hello.git/commit/?id=24225d705684322f482135e8a2d679485fce0811 https://git.savannah.gnu.org/cgit/hello.git/commit/?id=24225...
        picohik 2y ago
        > be able to use libraries that are decades old, that doesn't have any bugs for the stuff they expose and things just work. Acknowledging that all software has bugs is the first step to be able to produce high quality. > I mostly experience this in the Clojure ecosystem, but I'm sure it's true for other ecosystems too. How many decades exactly has your clojure existed without any bugs?
        account42 2y ago
    - sureIy 2y ago
      Yes, you definitely don't want to risk closing up all those holes discovered in the last 10 years, lots of people might be left out of your servers.

Widdershin 2y ago

Try add it to the Gemfile of a modern Rails project, the dependencies are very out of date and it won’t install.

sj26 2y ago
It's not designed to go in your Gemfile gem install mailcatcher :-)
snackernews 2y ago
Docs say > Please don't put mailcatcher into your Gemfile. It will conflict with your applications gems at some point.
- NewJazz 2y ago
  Commenter was just making the fair point that the dependencies are out of date. Maintenance doesn't always mean UI redesigns or non-compatible config changes. Sometimes it is just fixing bugs and updating or replacing old dependencies.
bdcravens 2y ago
I always run Mailcatcher as a standalone Docker image (I'm already using Docker Compose for development), with no issues.