Request to follow SemVer/mention it in homepage

Request to follow SemVer/mention it in homepage

[Pirate Praveen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

Do you follow Semantic Versioning as defined by semver.org? If yes,
can you mention it on the homepage? If not, can you consider it?

It will help us a lot in maintain rails applications in debian. We
like to keep only one version of any app/lib in debian and if you can
guarantee Semantic Versioning rails apps using unicorn could declare a
looser dependency rather than upto the patch version. Now gitlab
defines unicorn ~> 4.8.3 and diaspora defines ~> 4.9.0 If you are
following Semantic Versioning they could change it to ~> 4.8 and ~>
4.9 and 4.9.0 will satisfy both. Currently debian has 4.9.0 and it
does not match ~> 4.8.3

Thanks
Praveen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWCjHxAAoJEM4fnGdFEsIqsLEP/3A/+u8fZu9Pj4feOTH+gj/X
/ziFme3s+QbcEWMzFAyYK6wBE9mHb3BP/iALy3oTHmuPvyMjY5uhszeh/npggRl9
K1mkoCh97c/ri4HE09R90cnuRiYNV/Jh7JFNGUDYcMSBXMYJ0aGJVnBEbMQeQd4p
Gk771D2o4diH5JdLIWHObp2o3t06nG0pjKFexylBuW42RXpaYneCymPVNIZFGavk
6gyVzuM4TEWziokHQJuz36wD8yZ/zrdiOyl7kd2IV0D1mVKoezSfdm6TOQ8t53gV
bYAXBxA8Y7wtMu/8rH8T4xhhtT53JlEtWcXPXRrxM6Afu56oFmWFIKInTXSd12nY
wCfXMlDeirV2774H8MaSJTXvUSjQ5NcbT8JYj8IfS9xjL3aquJCqr2Y4JXYkMRlh
4q/gWsSwhemjAPcqk7fz5Jwj/nC5Zs8FD68apbZosA6SINsRXj9t7sSKgLFqhLcT
uBhdaBwsxtQ49yJfCHF51lD3g7Fd7aeEh8ZYSru6aPyZD81srpX6UU6yIebvsuox
/yEzxz/NLLvxz3k1VepD6he/DKpt0ApT+6HsF5XjxaARLs9s+yy53Oj7srlru/R9
cK4Q/LLW9fLXexFdKU9oenG9L7M9OOgua/Khlwn02g2yM5P7YBQKs/KEtXMNeJra
cFiSbt+EMxSsqo9QlJ1v
=78fV
-----END PGP SIGNATURE-----

Re: Request to follow SemVer/mention it in homepage

[Eric Wong]

Pirate Praveen <praveen@debian.org> wrote:
> Do you follow Semantic Versioning as defined by semver.org? If yes,
> can you mention it on the homepage? If not, can you consider it?

Maybe we follow semver...

No, I'd rather not mention it on the homepage or be formally/officially
bound to it (see below)

I have considered it in the past, but decided against it...

unicorn is on the verge of becoming 5.x:

This is for internal changes which some weirdo projects (notably
Rainbows!) rely on; but was never considered public API or marketed
as such.  I absolutely do not want people building server-specific
apps when Rack exists.

Rack will also hit 2.x soon, but regardless of incompatible changes
in Rack, unicorn must remain compatible with both 1.x and 2.x for
practical reasons.

> It will help us a lot in maintain rails applications in debian. We
> like to keep only one version of any app/lib in debian and if you can
> guarantee Semantic Versioning rails apps using unicorn could declare a
> looser dependency rather than upto the patch version. Now gitlab
> defines unicorn ~> 4.8.3 and diaspora defines ~> 4.9.0 If you are
> following Semantic Versioning they could change it to ~> 4.8 and ~>
> 4.9 and 4.9.0 will satisfy both. Currently debian has 4.9.0 and it
> does not match ~> 4.8.3

Tying a Rack app to unicorn is totally, completely wrong and defeats the
point of Rack.

Honestly, I could understand tying an app to thin with it's EM-specific
API, but unicorn(!?!?)  Even if an app isn't thread-safe, it should
still work in passenger, thin, or puma/webrick configured for a
single-thread...


Regardless of a formalities such as semver, I'll work to ensure unicorn
can be compatible[1] with any Rack apps in Debian main.
Heck, perhaps Rack 0.9.x still works (assuming the installed Ruby
version supports it).

Just let us know what real problems you find, they will be fixed.

Fwiw, Debian is my preferred platform and I can stay 100% within email
with the Debian BTS + lists.


[1] I would never say unicorn is the best choice for all apps,
    but it should at least limp along with sufficiently loose
    definitions of "working", perhaps with hundreds of inefficient
    processes in some cases.

Re: Request to follow SemVer/mention it in homepage

[Lin Jen-Shin (godfat)]

On Tue, Sep 29, 2015 at 3:36 PM, Eric Wong <e@80x24.org> wrote:
> Pirate Praveen <praveen@debian.org> wrote:
[...]
>> It will help us a lot in maintain rails applications in debian. We
>> like to keep only one version of any app/lib in debian and if you can
>> guarantee Semantic Versioning rails apps using unicorn could declare a
>> looser dependency rather than upto the patch version. Now gitlab
>> defines unicorn ~> 4.8.3 and diaspora defines ~> 4.9.0 If you are
>> following Semantic Versioning they could change it to ~> 4.8 and ~>
>> 4.9 and 4.9.0 will satisfy both. Currently debian has 4.9.0 and it
>> does not match ~> 4.8.3
>
> Tying a Rack app to unicorn is totally, completely wrong and defeats the
> point of Rack.
>
> Honestly, I could understand tying an app to thin with it's EM-specific
> API, but unicorn(!?!?)  Even if an app isn't thread-safe, it should
> still work in passenger, thin, or puma/webrick configured for a
> single-thread...

I guess the issue is that people need to specify which server they're
using in their Gmefile when bundler is used to launch the application.

I don't think it's a good idea to bind to a specific version though.
Upgrading unicorn never breaks anything for me.

p.s. Personally I never liked the idea of semantic versioning either,
unless there's a clearly defined API like Rack's SPEC.

Re: Request to follow SemVer/mention it in homepage

[Pirate Praveen]

On २९ सप्टेंबर, २०१५ १:०६:५० [PM] IST, Eric Wong <e@80x24.org> wrote:
>Pirate Praveen <praveen@debian.org> wrote:
>> Do you follow Semantic Versioning as defined by semver.org? If yes,
>> can you mention it on the homepage? If not, can you consider it?
>
>Maybe we follow semver...
>
>No, I'd rather not mention it on the homepage or be formally/officially
>bound to it (see below)
>
>I have considered it in the past, but decided against it...
>
>unicorn is on the verge of becoming 5.x:
>
>This is for internal changes which some weirdo projects (notably
>Rainbows!) rely on; but was never considered public API or marketed
>as such.  I absolutely do not want people building server-specific
>apps when Rack exists.

Can you consider SemVer from 5.x?

>Rack will also hit 2.x soon, but regardless of incompatible changes
>in Rack, unicorn must remain compatible with both 1.x and 2.x for
>practical reasons.
>
>> It will help us a lot in maintain rails applications in debian. We
>> like to keep only one version of any app/lib in debian and if you can
>> guarantee Semantic Versioning rails apps using unicorn could declare
>a
>> looser dependency rather than upto the patch version. Now gitlab
>> defines unicorn ~> 4.8.3 and diaspora defines ~> 4.9.0 If you are
>> following Semantic Versioning they could change it to ~> 4.8 and ~>
>> 4.9 and 4.9.0 will satisfy both. Currently debian has 4.9.0 and it
>> does not match ~> 4.8.3
>
>Tying a Rack app to unicorn is totally, completely wrong and defeats
>the
>point of Rack.
>
>Honestly, I could understand tying an app to thin with it's EM-specific
>API, but unicorn(!?!?)  Even if an app isn't thread-safe, it should
>still work in passenger, thin, or puma/webrick configured for a
>single-thread...
>
>
>Regardless of a formalities such as semver, I'll work to ensure unicorn
>can be compatible[1] with any Rack apps in Debian main.
>Heck, perhaps Rack 0.9.x still works (assuming the installed Ruby
>version supports it).
>
>Just let us know what real problems you find, they will be fixed.

If you can convince gitlab to declare ~> 4.8 and assure it will work with 4.9, that will solve the issue for now.

See https://gitlab.com/gitlab-org/gitlab-ce/issues/2820

Also if you can help convinse diaspora upstream to declare a looser dependency, that will also help.

>Fwiw, Debian is my preferred platform and I can stay 100% within email
>with the Debian BTS + lists.

Glad to know.

>
>[1] I would never say unicorn is the best choice for all apps,
>    but it should at least limp along with sufficiently loose
>    definitions of "working", perhaps with hundreds of inefficient
>    processes in some cases.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Request to follow SemVer/mention it in homepage

[Jérémy Lecour]

On Tue, Sep 29, 2015 at 9:36 AM, Eric Wong <e@80x24.org> wrote:
> Tying a Rack app to unicorn is totally, completely wrong and defeats the
> point of Rack.

I completely agree with that statement.

However, having an app with hard dependency on a specific app server
is not the same a providing a default setup for a given app server.

For example, an app like Gitlab, Discourse or whatever might provide a
default good configuration for Unicorn, a set of optimisations in the
context of a Unicorn (pre/post fork instructions…) and have something
that works great out of the box, even if it's not restricted to
Unicorn.
Someone who would want to change to Passenger, Puma or else would have
to adapt the configuration and port the optimizations, but the app
would work the same as with Unicorn, without crippled features.
Someone who wouldn't change or tweak anything would have a good
setting by default.

-- 
Jérémy Lecour :
http://jeremy.wordpress.com - http://twitter.com/jlecour

Re: Request to follow SemVer/mention it in homepage

[Eric Wong]

Pirate Praveen <praveen@debian.org> wrote:
> On २९ सप्टेंबर, २०१५ १:०६:५० [PM] IST, Eric Wong <e@80x24.org> wrote:
> >Pirate Praveen <praveen@debian.org> wrote:
> >> Do you follow Semantic Versioning as defined by semver.org? If yes,
> >> can you mention it on the homepage? If not, can you consider it?

<snip>

> >I have considered it in the past, but decided against it...
> >
> >unicorn is on the verge of becoming 5.x:
> >
> >This is for internal changes which some weirdo projects (notably
> >Rainbows!) rely on; but was never considered public API or marketed
> >as such.  I absolutely do not want people building server-specific
> >apps when Rack exists.
> 
> Can you consider SemVer from 5.x?

Again, the answer is "no".  I do not want people to depend on unicorn
providing a stable API of any sort.  Even if in practice and history
it does: the config file directives and internal constant names
haven't changed at all in 5-6 years and there are no plans to change it.

> >Regardless of a formalities such as semver, I'll work to ensure unicorn
> >can be compatible[1] with any Rack apps in Debian main.
> >Heck, perhaps Rack 0.9.x still works (assuming the installed Ruby
> >version supports it).
> >
> >Just let us know what real problems you find, they will be fixed.
> 
> If you can convince gitlab to declare ~> 4.8 and assure it will work
> with 4.9, that will solve the issue for now.
> 
> See https://gitlab.com/gitlab-org/gitlab-ce/issues/2820

That's not a real compatibility bug with unicorn itself.  Again, it's
wrong of them to have a dependency on any Rack server at all.

> Also if you can help convinse diaspora upstream to declare a looser
> dependency, that will also help.
> 
> >Fwiw, Debian is my preferred platform and I can stay 100% within email
> >with the Debian BTS + lists.

I am only doing plain-text email.  I'm done with websites requiring
login + registration.

Re: Request to follow SemVer/mention it in homepage

[Eric Wong]

Jérémy Lecour <jeremy.lecour@gmail.com> wrote:
> On Tue, Sep 29, 2015 at 9:36 AM, Eric Wong <e@80x24.org> wrote:
> > Tying a Rack app to unicorn is totally, completely wrong and defeats the
> > point of Rack.
> 
> I completely agree with that statement.
> 
> However, having an app with hard dependency on a specific app server
> is not the same a providing a default setup for a given app server.
> 
> For example, an app like Gitlab, Discourse or whatever might provide a
> default good configuration for Unicorn, a set of optimisations in the
> context of a Unicorn (pre/post fork instructions…) and have something
> that works great out of the box, even if it's not restricted to
> Unicorn.

Right, Debian has Recommends/Suggests: fields for soft dependencies; but
I still consider that overkill.

> Someone who would want to change to Passenger, Puma or else would have
> to adapt the configuration and port the optimizations, but the app
> would work the same as with Unicorn, without crippled features.
> Someone who wouldn't change or tweak anything would have a good
> setting by default.

Perhaps there could be per-server Debian packages such as:

	gitlab-webrick  (should be the default)
	gitlab-puma
	gitlab-passenger
	gitlab-unicorn
	...

Given unicorn has always required the use of nginx for exposure to
public clients, unicorn is perhaps the worst choice as a default
server for people unwilling to read documentation and edit config
files.

Re: Request to follow SemVer/mention it in homepage

[Pirate Praveen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wednesday 30 September 2015 01:06 AM, Eric Wong wrote:
> Pirate Praveen <praveen@debian.org> wrote:
>> On २९ सप्टेंबर, २०१५ १:०६:५० [PM] IST, Eric Wong <e@80x24.org> 
>> wrote:
>>> Pirate Praveen <praveen@debian.org> wrote:
>>>> Do you follow Semantic Versioning as defined by semver.org? 
>>>> If yes, can you mention it on the homepage? If not, can you 
>>>> consider it?
> 
> <snip>
> 
>>> I have considered it in the past, but decided against it...
>>> 
>>> unicorn is on the verge of becoming 5.x:
>>> 
>>> This is for internal changes which some weirdo projects 
>>> (notably Rainbows!) rely on; but was never considered public 
>>> API or marketed as such.  I absolutely do not want people 
>>> building server-specific apps when Rack exists.
>> 
>> Can you consider SemVer from 5.x?
> 
> Again, the answer is "no".  I do not want people to depend on 
> unicorn providing a stable API of any sort.  Even if in practice 
> and history it does: the config file directives and internal 
> constant names haven't changed at all in 5-6 years and there are
> no plans to change it.

Can you mention the recommended way of adding unicorn in a Gemfile in
your home page?

gitlab and diaspora has unicorn in their Gemfile, for a user they want
gitlab or diaspora and they don't care if its using unicorn or puma or
passenger.

I need some kind of an official statement about compatibility which I
can show to projects like gitlab and diaspora, so they don't insist on
exact patch release of unicorn. I could patch the Gemfile, but that
adds extra burden on me as a maintainer which I'd like to avoid if
possible.

>>> Regardless of a formalities such as semver, I'll work to
>>> ensure unicorn can be compatible[1] with any Rack apps in
>>> Debian main. Heck, perhaps Rack 0.9.x still works (assuming
>>> the installed Ruby version supports it).
>>> 
>>> Just let us know what real problems you find, they will be 
>>> fixed.
>> 
>> If you can convince gitlab to declare ~> 4.8 and assure it will 
>> work with 4.9, that will solve the issue for now.
>> 
>> See https://gitlab.com/gitlab-org/gitlab-ce/issues/2820
> 
> That's not a real compatibility bug with unicorn itself.  Again, 
> it's wrong of them to have a dependency on any Rack server at all.
> 
>> Also if you can help convinse diaspora upstream to declare a 
>> looser dependency, that will also help.
>> 
>>> Fwiw, Debian is my preferred platform and I can stay 100% 
>>> within email with the Debian BTS + lists.
> 
> I am only doing plain-text email.  I'm done with websites requiring
> login + registration.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWDAf9AAoJEM4fnGdFEsIqYV0P/AmIFATrnxSF4V5Q5v05LT5G
LcVkXCzMhQYnPaVYwiAEi5JLGkiFw2r2Y5kWgF3WLynXHqWmUpGoNLEsG5tZG38V
109RYYKG5VgsGw6HlIoOwpy61MF9/d29+CRDXvLs0q7wc1/CbDEYqnhwLvKKOT9o
xZBD3bXsLuXiRl/BR8xk1q5fy4oS0rNnTU4MWcc8pEKU3KFE0xkXqA5WVS3ENShg
WLfqlUnll2SnQwyR1FzqFJws5OzejKpdNRZK1IOD1ivMd8aBVY25+0u6Q3o/2h/J
dW4ID9QV6R1fCtLybKqkI/fwljlKGs+shY+5lvUqE2KSYe8gwyHm6r1DslprzwM6
QhzLXqBtvDxSxX41sbcr12SoEt7poRztr+8gFXqni+iTkoljgsmODQMWX/ed/9O8
AekqfSrA//K1JfUpGKWHr1+UXhijHggYcKi0eoCJA2GH5ijLu5DIglEuGCQtthl9
z4/aI/na1M7goqBKw1Qtuxc/AHlBAkDcsott5n+4FIQInc5ooiyj54+Sek1AZNWw
/pp5F6z3axPgH3+h26Jf4W8OHl58gUeht9G7sl2j5GwMDkVSOtwlgwhLEYWdZ8Mw
pZcDXl/0VieD6LBFEh3N5MfkP+n3aYHrenCbsxRBh/jn6/+wczoUruNYl0SbSgUh
62qZ2q/7NgvHBdVPtXaB
=F2uT
-----END PGP SIGNATURE-----

Re: Request to follow SemVer/mention it in homepage

[Eric Wong]

Pirate Praveen <praveen@debian.org> wrote:
> Can you mention the recommended way of adding unicorn in a Gemfile in
> your home page?

I'm not very knowledgeable about bundler, but app servers probably
should not be in any packaged Gemfile at all.

> gitlab and diaspora has unicorn in their Gemfile, for a user they want
> gitlab or diaspora and they don't care if its using unicorn or puma or
> passenger.
> 
> I need some kind of an official statement about compatibility which I
> can show to projects like gitlab and diaspora, so they don't insist on
> exact patch release of unicorn. I could patch the Gemfile, but that
> adds extra burden on me as a maintainer which I'd like to avoid if
> possible.

"Official statements" do not have much weight behind them; history does.

They can look at the git history (especially that of manpages and
documentation) to see the only feature removals were for undocumented
cruft.

Personally, I intensely dislike "official" things; so people shouldn't
take what I (or anybody) writes as gospel.

Re: Request to follow SemVer/mention it in homepage

[Pirate Praveen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

[copying jhass, maintainer of diaspora]

jhass, they prefer email to issue tracker so I copied you here.

You can see the complete discussion here
http://bogomips.org/unicorn-public/560A31F1.3060608%40debian.org/t/#u

On Thursday 01 October 2015 01:21 AM, Eric Wong wrote:
> Pirate Praveen <praveen@debian.org> wrote:
>> Can you mention the recommended way of adding unicorn in a
>> Gemfile in your home page?
> 
> I'm not very knowledgeable about bundler, but app servers probably 
> should not be in any packaged Gemfile at all.

May be jhass can explain the rationale for adding unicorn to Gemfile
better.

>> gitlab and diaspora has unicorn in their Gemfile, for a user they
>> want gitlab or diaspora and they don't care if its using unicorn
>> or puma or passenger.
>> 
>> I need some kind of an official statement about compatibility
>> which I can show to projects like gitlab and diaspora, so they
>> don't insist on exact patch release of unicorn. I could patch the
>> Gemfile, but that adds extra burden on me as a maintainer which
>> I'd like to avoid if possible.
> 
> "Official statements" do not have much weight behind them; history
> does.
> 
> They can look at the git history (especially that of manpages and 
> documentation) to see the only feature removals were for
> undocumented cruft.

jhass, can we relax unicorn dependency to ~> 4.9?

> Personally, I intensely dislike "official" things; so people
> shouldn't take what I (or anybody) writes as gospel.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWDLz7AAoJEM4fnGdFEsIqN5MQAKEWGiI3IBfOYmquIplkG/7E
5gohMKsCDJlj6lgqaPIHzvekIW7ssNlxKv9cmeA/v+uNNCKZw6OEw4dmkfJHq5VV
mQ+bBCKkymTFR7ZrIWIs43D0E4To4Sf5LD6MpECiQI1MypFoy66rl0FqJR9PQcF0
nPqcI8LDEICePZwgPdeRrTrS4vCfr4U+BmQWuYovIjwAGEoslnNeblKE+q4LcnGu
09XWelo8eYL62EI6XB92KWCFx0isiEBGQK0PzLqZUbWz17Y7kNMxeAnfmPZQFoe5
4qI7SEtSusFU3OW2t6Eyj6/bh+hP7W2jtMnub+B+QBBUqjf50WV0p4FqUUXMzheS
wDJbtVdYNbNO4f6cWLMVGC18jOVzJw86luc+QoxptTCShku+gFROrkA4w+ciHpNk
2x92Z/S2ejYZlJKGhH97KqMe2gAKgikwYk2zgjSLtpxxrAPiE2nP3tX5KKOG7BNO
iUPdftzLD04oEr21QMb/gRpCEP0f8zsECK/vkpB4VjfjM9HhgEDJZzOfOTvHs04b
avILU6iTUQkSMcWhtdp8bxsifhD+sSjhThWbbMyomV9LdjVBf9gf3J4pzTALT5Rf
rc+V0Gf+dScHpSFMphY7Y7vKuS/PjKvLq1qD2rAsOtDVPDxVT99HsVTUUNR6lAY0
eHegzfNqE/oqHosK1dLN
=AglS
-----END PGP SIGNATURE-----

Re: Request to follow SemVer/mention it in homepage

[Pirate Praveen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

[dropping jhass]

He says "It's probably just conflicting opinion, distributing Ruby
applications to untrained people is still uncommon"

On Thursday 01 October 2015 10:26 AM, Pirate Praveen wrote:
> [copying jhass, maintainer of diaspora]
> 
> jhass, they prefer email to issue tracker so I copied you here.
> 
> You can see the complete discussion here 
> http://bogomips.org/unicorn-public/560A31F1.3060608%40debian.org/t/#u
>
>  On Thursday 01 October 2015 01:21 AM, Eric Wong wrote:
>> Pirate Praveen <praveen@debian.org> wrote:
>>> Can you mention the recommended way of adding unicorn in a 
>>> Gemfile in your home page?
> 
>> I'm not very knowledgeable about bundler, but app servers
>> probably should not be in any packaged Gemfile at all.
> 
> May be jhass can explain the rationale for adding unicorn to
> Gemfile better.

jhass: "Adding unicorn to the Gemfile eases installation by taking a
step out of it, allows site local installation of it
(--path/--deployment) and ensures the right version so our
integrations (config/unicorn.rb, config/eye.rb, script/server) don't
break."

With debian packaging, our aim is to get a user setup an application
like gitlab or diaspora, just using the package manager they are
already familiar with. They don't have to know what language it is
written, what framework or application server or what database it is
using, all they are interested is the application specific configuration
.

How much compatibility we can expect for config/unicorn.rb?

>>> gitlab and diaspora has unicorn in their Gemfile, for a user
>>> they want gitlab or diaspora and they don't care if its using
>>> unicorn or puma or passenger.
>>> 
>>> I need some kind of an official statement about compatibility 
>>> which I can show to projects like gitlab and diaspora, so they 
>>> don't insist on exact patch release of unicorn. I could patch
>>> the Gemfile, but that adds extra burden on me as a maintainer
>>> which I'd like to avoid if possible.
> 
>> "Official statements" do not have much weight behind them;
>> history does.
> 
>> They can look at the git history (especially that of manpages and
>>  documentation) to see the only feature removals were for 
>> undocumented cruft.
> 
> jhass, can we relax unicorn dependency to ~> 4.9?
> 
>> Personally, I intensely dislike "official" things; so people 
>> shouldn't take what I (or anybody) writes as gospel.
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWDRZyAAoJEM4fnGdFEsIq+HsP/1T373t8YXTm0e+EAwJxcGaH
SpSdhDrZGcz9oI3vmwx8N1dX86/28hZzU5TEwi/xB4KN/Xzd+fZwTp1lpwTMcEI9
rSUPnknDo8FatT17fg6B99RmB30uIRbIgVgzfUIj30LL0bGC0ulVlVZEZ95jURb4
YVwXuxgRUH5gV7Ql/LpkBnnTni6kgy9Jsrq7ShaaxGNY2NsMrV3hAeN2aSuSJNU/
jUOZCjXzoDKdGS/pfdPTOdAHVSzKtnJ9cZhktBPbSmvHrJ0Zx7Di6zG8TJAQO+EG
n3qlR/ghke4MzNWIprVcqxH37ML6ww913UBCyVRGNOtU+c2/sEd+AlyIjBIzRK9n
Nq5jpcAd5doJHgfIesTxWSX4QhjH6XPqPpbMvIFEwHHpiv8lNi/+Rp5mTFAHiEJY
zEQCSOQmOBiLY56q/e/OVnK+L+6s9gCxYkynzsmgfrJ0HjBd9DNENMpKgboUj3sN
8I+CqerNq3h4lSvnAyb9pdUiAmSv+uD4aMXtgCltWlcC2cNQL51w6OKBO8+hKMuw
uKFihtyUkSD/51e4vmx5lVmz0+7vXPY1CyezbreX50V/zJcYMhJy0Cg42L+BGEWu
8lqrLxoCxua7j5p+hya1D0xuCvQ9eVKmfA2oXwJ7ChR6ZdACMfV6vn47UzYXIyBk
7HbtK7HFc7QVuC3Xg/e8
=JLvl
-----END PGP SIGNATURE-----

Re: Request to follow SemVer/mention it in homepage

[Eric Wong]

Pirate Praveen <praveen@debian.org> wrote:
> With debian packaging, our aim is to get a user setup an application
> like gitlab or diaspora, just using the package manager they are
> already familiar with. They don't have to know what language it is
> written, what framework or application server or what database it is
> using, all they are interested is the application specific configuration

I suggest webrick.  It's not bad nowadays with Ruby 2.x and is the only
standard server in Ruby.  For out-of-the-box use, unicorn is probably
the worst possible default since it requires nginx.

> How much compatibility we can expect for config/unicorn.rb?

I assume you mean the Unicorn::Configurator class (in
lib/unicorn/configurator.rb).  That won't change, it hasn't
changed since 2009 as I mentioned in:

http://bogomips.org/unicorn-public/20150929193627.GA7572%40dcvr.yhbt.net/