On 11/10/13, Andrej Mitrovic wrote:
> On 11/10/13, Sönke Ludwig wrote:
>> I've also thought about that in the past days, shouldn't be difficult to
>> add (an RSS feed could also be interesting).
>
> I didn't want to appear needy, but yes an RSS feed would be awesome.
Excellent, I see you've adde
On 11/10/13, Sönke Ludwig wrote:
> I've also thought about that in the past days, shouldn't be difficult to
> add (an RSS feed could also be interesting).
I didn't want to appear needy, but yes an RSS feed would be awesome.
Would be nice if you could subscribe to a daily/weekly mail of the new
/updated packages .
On 10 Nov 2013 10:25, "Sönke Ludwig" wrote:
> Am 09.11.2013 18:18, schrieb evilrat:
>
>> On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic wrote:
>>
>>>
>>> Is it possible to add a feature to so
Am 09.11.2013 18:18, schrieb evilrat:
On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic wrote:
Is it possible to add a feature to sort the view by the added date of
a package (rather than just updated/name sorting)? Sometimes I'd like
to see which packages are new in the registry.
On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic
wrote:
Is it possible to add a feature to sort the view by the added
date of
a package (rather than just updated/name sorting)? Sometimes
I'd like
to see which packages are new in the registry.
that would be really useful. who kn
On 10/16/13, Sönke Ludwig wrote:
> The DUB package registry [1] has finally gained support for the text and
> category based search of packages.
Is it possible to add a feature to sort the view by the added date of
a package (rather than just updated/name sorting)? Sometimes I'd like
to see which
On Friday, 18 October 2013 at 10:23:20 UTC, Sönke Ludwig wrote:
Am 17.10.2013 20:25, schrieb Tourist:
On Thursday, 17 October 2013 at 18:22:02 UTC, Sönke Ludwig
wrote:
Am 16.10.2013 21:01, schrieb Sönke Ludwig:
The DUB package registry [1] has finally gained support for
the text and
category b
Am 17.10.2013 20:25, schrieb Tourist:
On Thursday, 17 October 2013 at 18:22:02 UTC, Sönke Ludwig wrote:
Am 16.10.2013 21:01, schrieb Sönke Ludwig:
The DUB package registry [1] has finally gained support for the text and
category based search of packages. There is also a category for D
standard
Am 18.10.2013 08:47, schrieb Suliman:
code.dlang.org
Does we should have cats? maybe the organization by tags is better?
You mean like a flat list of tags?
Currently it's something like hierarchical tags. Each package can have
multiple categories, and the specific categories, as well as the
code.dlang.org
Does we should have cats? maybe the organization by tags is
better?
On Thursday, 17 October 2013 at 18:22:02 UTC, Sönke Ludwig wrote:
Am 16.10.2013 21:01, schrieb Sönke Ludwig:
The DUB package registry [1] has finally gained support for
the text and
category based search of packages. There is also a category
for D
standard library candidate modules, as has been
Am 16.10.2013 21:01, schrieb Sönke Ludwig:
The DUB package registry [1] has finally gained support for the text and
category based search of packages. There is also a category for D
standard library candidate modules, as has been suggested recently.
If you already have any registered packages, p
Am 17.10.2013 17:02, schrieb Sönke Ludwig:
Am 17.10.2013 16:59, schrieb Jacob Carlborg:
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two target
Am 17.10.2013 16:59, schrieb Jacob Carlborg:
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two targets.
What's happens then with the main/super
On 2013-10-17 15:53, Sönke Ludwig wrote:
Added APSL-2.0 (Apple Public Source License) and MS-PL (Microsoft Public
License).
Cool, thanks.
--
/Jacob Carlborg
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two targets.
What's happens then with the main/super package, in regards to licensing?
--
/Jacob
On Thursday, 17 October 2013 at 13:26:06 UTC, Jacob Carlborg
wrote:
On 2013-10-17 14:06, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that
both
licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets,
The only license JSON that looks valid is the string. Simple bracketing
will suffice for complex licenses.
On 17 Oct 2013 16:05, "Sönke Ludwig" wrote:
> Am 17.10.2013 15:28, schrieb Jacob Carlborg:
>
>> On 2013-10-17 14:33, Sönke Ludwig wrote:
>>
>> "dub publish" sounds like something that may c
Am 17.10.2013 15:28, schrieb Jacob Carlborg:
On 2013-10-17 14:33, Sönke Ludwig wrote:
"dub publish" sounds like something that may considerably increase the
complexity of the command line tool, especially in the long term, and it
also increases the coupling to the public registry, whereas now i
Am 17.10.2013 15:31, schrieb Jacob Carlborg:
On 2013-10-17 11:33, Sönke Ludwig wrote:
There has been another important change that requires existing packages
to be updated: All packages must now have the fields "description" and
"license" present to be published. The license field has to be set
On Thursday, 17 October 2013 at 13:31:06 UTC, Jacob Carlborg
wrote:
On 2013-10-17 11:33, Sönke Ludwig wrote:
There has been another important change that requires existing
packages
to be updated: All packages must now have the fields
"description" and
"license" present to be published. The lice
Am 17.10.2013 15:26, schrieb Jacob Carlborg:
On 2013-10-17 14:06, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that both
licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets, that
don't share any cod
On 2013-10-17 11:33, Sönke Ludwig wrote:
There has been another important change that requires existing packages
to be updated: All packages must now have the fields "description" and
"license" present to be published. The license field has to be set
according to the specification [1]. All existi
On 2013-10-17 14:06, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that both
licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets, that
don't share any code. I don't know if that's possible in Dub, bu
On 2013-10-17 14:33, Sönke Ludwig wrote:
"dub publish" sounds like something that may considerably increase the
complexity of the command line tool, especially in the long term, and it
also increases the coupling to the public registry, whereas now it just
needs a very small HTTP API that can be
On Thursday, 17 October 2013 at 12:27:02 UTC, Sönke Ludwig wrote:
Am 17.10.2013 14:13, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig
wrote:
If you have per-file differences, then this in fact means
that both
licenses need to be obeyed when using the package.
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
On 10/17/13, Sönke Ludwig wrote:
Having a single compact name reduces the
chances for errors
Speaking of which, if I forget to add the license to a package file is
there any way to get this information from the server? I mean like a
page saying th
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
Personally I think it would be better if we had a "dub publish"
command, which would then error back if the server rejects the
package, rather than make this whole process automated based on
searching github (I assume this is how the dub server works
Am 17.10.2013 14:13, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that both
licenses need to be obeyed when using the package. If those licenses
are incompatible, that's a problem of the packag
On 10/17/13, Sönke Ludwig wrote:
> Having a single compact name reduces the
> chances for errors
Speaking of which, if I forget to add the license to a package file is
there any way to get this information from the server? I mean like a
page saying that my package was rejected because it's missin
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that
both licenses need to be obeyed when using the package. If
those licenses are incompatible, that's a problem of the
package combining them - it's basically unusable t
Am 17.10.2013 13:42, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 10:39:45 UTC, Sönke Ludwig wrote:
But one potential issue just occurred to me. What if a product is
licensed under multiple licenses that must _all_ apply? That would
basically be "MPL-2.0 and Apache-1.0" instead of "or
On Thursday, 17 October 2013 at 10:39:45 UTC, Sönke Ludwig wrote:
But one potential issue just occurred to me. What if a product
is licensed under multiple licenses that must _all_ apply? That
would basically be "MPL-2.0 and Apache-1.0" instead of "or".
This is something that happens quite freq
But one potential issue just occurred to me. What if a product
is licensed under multiple licenses that must _all_ apply? That
would basically be "MPL-2.0 and Apache-1.0" instead of "or".
This is something that happens quite frequently when code is
taken from multiple projects or when the licen
Am 17.10.2013 12:14, schrieb ilya-stromberg:
Add abbility to add the array with licenses:
"license": ["BSL-1.0", "AFL-3.0", "public domain"]
I think it's better than
"license": "BSL-1.0 or AFL-3.0 or public domain"
There will still be the need to specify "or later", so this will only
make it p
On Thursday, 17 October 2013 at 10:07:40 UTC, Sönke Ludwig wrote:
Am 17.10.2013 11:55, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig
wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the
Am 17.10.2013 11:55, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the fields
"description" and "license" present to be published. The lic
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the fields
"description" and "license" present to be published. The
license field has to be set according to the sp
There has been another important change that requires existing packages
to be updated: All packages must now have the fields "description" and
"license" present to be published. The license field has to be set
according to the specification [1]. All existing branches and version
tags stay unaff
Am 16.10.2013 21:58, schrieb Andrej Mitrovic:
On 10/16/13, Sönke Ludwig wrote:
It's still all a little rough around the edges. Any bugs can be reported
on the issue tracker [3] or discussed in the forum [4].
[1]: http://code.dlang.org
[2]:
https://github.com/rejectedsoftware/dub-registry/blob/
On 10/16/13, Sönke Ludwig wrote:
> It's still all a little rough around the edges. Any bugs can be reported
> on the issue tracker [3] or discussed in the forum [4].
>
> [1]: http://code.dlang.org
> [2]:
> https://github.com/rejectedsoftware/dub-registry/blob/master/categories.json
> [3]: https://
Am 16.10.2013 21:24, schrieb ponce:
On Wednesday, 16 October 2013 at 19:23:54 UTC, ponce wrote:
Great! But I think the eloty categories must go until needed.
I meant "empty".
https://github.com/rejectedsoftware/dub-registry/issues/21
On Wednesday, 16 October 2013 at 19:23:54 UTC, ponce wrote:
Great! But I think the eloty categories must go until needed.
I meant "empty".
On Wednesday, 16 October 2013 at 19:01:45 UTC, Sönke Ludwig wrote:
If you already have any registered packages, please log in and
add the proper categories to each of them ("My packages" ->
click on package name). Should there be no exact category
match, and that specific category is likely to
The DUB package registry [1] has finally gained support for the text and
category based search of packages. There is also a category for D
standard library candidate modules, as has been suggested recently.
If you already have any registered packages, please log in and add the
proper categorie
45 matches
Mail list logo