c-rack / cidr-elixir Goto Github PK

Thank you for merging #51 !
It would be nice if you could bump the version number, so we could get a new release on hex, without having to explicitly reference master. Last release was from 2017 as far as I can tell.

Now that we have a stable version and changed the license, I would like to release the current status as version 1.0 to indicate the stable status of this library (the hex.pm version badge would also become green then).

Of course, we should remove the deprecated start / end fields in the struct first (see #26), and then update the version. According to SemVer, that would be perfectly ok.

If no one objects, I would prepare and release 1.0 next weekend.

Hello. Is there any reason you hesitate to release 1.1.0? Changelog says there is 1.1.0 but it's not listed on hex.

https://hex.pm/packages/cidr

Would also be nice to see #44 too.

end is a (reserved?) keyword in Elixir, which we should avoid as a struct field name, see:
https://github.com/elixir-lang/elixir/blob/7b5f4a5842d05bf279b249078fd9051e3dcafa50/lib/elixir/src/elixir_tokenizer.erl#L1037

While this does not cause problems in actual code yet (except broken syntax highlighting), I would strongly advise to change the CIDR struct members start / end to first / last.

This will break backward compatibility, but I think it is better to change it now than later.

@duijf what do you think?

http://hexdocs.pm/cidr is currently a 404. It may be a good idea to publish the documentation there. Here is a tutorial on how to do it: https://hex.pm/docs/tasks#hex_docs

I would like to change the license of cidr-elixir from MIT to MPL.

According to the C4.1 process, the MPL is recommended to use:

The project SHALL use a share-alike license, such as the GPLv3 or a variant thereof (LGPL, AGPL), or the MPLv2.

@duijf would you agree to change to MPL?

Currently, match just returns true or false. However, it would be good to let callers know if there is an error in the ip-address they passed in. Currently CIDR.match(cidr, :test) returns false, but CIDR.match(cidr, "this should be an ip address") throws a matcherror.

You can also pass in any 4 or 6 tuple and there will not be any validation.

The way I see it, we can pick from two approaches:

Tagged tuples:

• When it's a match: {:ok, true}
• When it's not a match: {:ok, false}
• When the IP to match against is invalid: {:error, reason}.

Exceptions:

• When it's a match: true
• When it's not a match: false
• When the IP to match against is invalid: raise ArgumentError.

We can also support both, separate by function name: match for the first interface and match! for the second.

@c-rack what do you think?