I reviewed and pushed. There where some minor problems with the patches that I fixed, but I thought I would go over them. It looks like you did a bunch of development and then went back and tried commiting in a meaningful way. Thats awesome in general, but doing it that way makes it harder to make sure each commit is clean. Its better to commit on a regular basis as you develop and then merge those small commits together where needed and give them meaningful commit strings. Here is what I did.
Originally you had this + 18372372c71b0cd4ef0054671635bdc8faf3f945 added in module for semvar comparisons + 14adbe9372187cc49d90f004453217d62381524b added code for dealing with semvers + 2e438d0e97d2d710c38dd1c93c51190ae2f393e0 added code for dealing with strings. Initial commit for version strings + 3efb153e833358a0aec34a6dc8438a288613c54e fixed doc error - 07c86d652e4108c8781b0529dff815fa392c1b1d altered ordering on the fetch and find functions, version patch bumped because API is not yet final + ce3c34444c3c4c05e98692b69e1b3c7428386fbf export error, not sure why compiler did not complain I merged 1837 and 14adbe (the two semvar patches). On an initial introduction to the repo there isn't any need to represent your development trail. Better to have one complete patch that adds the functionality, its not a hard fast rule but squishes are easy. A bit of the ec_strings stuff made it into these patches. I removed them and added it to the strings patches. I merged 2e438, 3efb and ce3c3 into a single patch and added the strings bits from the other patches. I didn't do anything to 07c86. We ended up with the following three patches. commit 3c9e60c5a27f12762eec65b93d6e0682d3edefc3 Author: Martin J. Logan <[email protected]> Date: Sat Mar 12 22:10:12 2011 -0600 altered ordering on the fetch and find functions, version patch bumped Ordering altered to match existing list functions, Version patch bumped because because API is not yet final Signed-off-by: Eric Merritt <[email protected]> commit b4981ff4b5190024ed94d2b9121a39df0e1f32ac Author: Martin J. Logan <[email protected]> Date: Sat Mar 12 19:01:53 2011 -0600 added code for dealing with strings. Initial commit for version strings Signed-off-by: Eric Merritt <[email protected]> commit 9e6f98ba8138c0312a815bb44aba1d672b956860 Author: Martin J. Logan <[email protected]> Date: Sat Mar 12 17:54:33 2011 -0600 added in module for semvar comparisons This code implements comparisons using (list based) strings as semantic versions. It follows the stadard dictated by semvar.org. Signed-off-by: Eric Merritt <[email protected]> On Sun, Mar 13, 2011 at 1:05 PM, Martin Logan <[email protected]> wrote: > ha ha - I am foggy headed too so I can definitely understand > > On Sun, Mar 13, 2011 at 10:48 AM, Jordan Wilberding > <[email protected]> wrote: >> You can't do that to me when I'm on cold medicine ;) >> >> On Sun, Mar 13, 2011 at 11:46 AM, Martin Logan <[email protected]> >> wrote: >>> >>> Was joke, yes >>> >>> On Mar 13, 2011 7:36 AM, "Jordan Wilberding" <[email protected]> >>> wrote: >>> > Or I'd even go for ec_string and ec_bstring >>> > >>> > I just prefer things that are similar to look similar. Seeing ec_string >>> > and >>> > ec_bs wouldn't imply they are similar. >>> > >>> > JW >>> > >>> > On Sun, Mar 13, 2011 at 8:35 AM, Jordan Wilberding >>> > <[email protected]>wrote: >>> > >>> >> I'd prefer >>> >> >>> >> ec_str and ec_bin_str >>> >> >>> >> Thoughts? >>> >> >>> >> JW >>> >> >>> >> >>> >> On Sat, Mar 12, 2011 at 11:47 PM, Martin Logan >>> >> <[email protected]>wrote: >>> >> >>> >>> ec_BS ;-) >>> >>> >>> >>> On Sat, Mar 12, 2011 at 10:24 PM, Eric Merritt >>> >>> <[email protected]> >>> >>> wrote: >>> >>> > I agree with martin, I think of it as an optimization that gets used >>> >>> > where needed, so I tend not to use it much. I just want us to be >>> >>> > explicit about what type of string a string module is focused on. >>> >>> > Btw >>> >>> > ec_binary_string seams pretty long. >>> >>> > >>> >>> > On Sat, Mar 12, 2011 at 10:29 PM, Martin Logan >>> >>> > <[email protected]> >>> >>> wrote: >>> >>> >> lets have a ec_binary_string module as well. I consider binary >>> >>> >> strings >>> >>> >> an optimization typically and don't normally use them. >>> >>> >> >>> >>> >> On Sat, Mar 12, 2011 at 7:52 PM, Jordan Wilberding >>> >>> >> <[email protected]> wrote: >>> >>> >>> This is a touch choice. My personal opinion is binary strings, but >>> >>> that >>> >>> >>> hasn't been well adopted yet. Any reason we can't support both? >>> >>> >>> Thanks! >>> >>> >>> JW >>> >>> >>> >>> >>> >>> On Sat, Mar 12, 2011 at 8:15 PM, Eric Merritt >>> >>> >>> <[email protected] >>> >>> > >>> >>> >>> wrote: >>> >>> >>>> >>> >>> >>>> As we are gearing up for new development and you are mentioning >>> >>> >>>> strings I think its probably a good idea to explicitly settle on >>> >>> >>>> the >>> >>> >>>> strings we are going to us. Lists or Binaries? I suspect lists >>> >>> >>>> and >>> >>> >>>> thats what I would vote for but it is something we should come to >>> >>> >>>> agreement on. >>> >>> >>>> >>> >>> >>>> On Sat, Mar 12, 2011 at 8:04 PM, Martin Logan < >>> >>> [email protected]> >>> >>> >>>> wrote: >>> >>> >>>> > All, I pushed code to my master branch that contains two new >>> >>> modules. >>> >>> >>>> > The first is ec_semver which contains a function for comparing >>> >>> semver >>> >>> >>>> > strings. The second is ec_string which starts the module for >>> >>> >>>> > string >>> >>> >>>> > handling. I added a function that compares pretty much any >>> >>> resonable >>> >>> >>>> > version string out there. These functions are particularly >>> >>> >>>> > useful >>> >>> for >>> >>> >>>> > sorting by versions. >>> >>> >>>> > >>> >>> >>>> > Please take a look. >>> >>> >>>> > >>> >>> >>>> > -- >>> >>> >>>> > Martin Logan >>> >>> >>>> > Erlang & OTP in Action (Manning) http://manning.com/logan >>> >>> >>>> > http://twitter.com/martinjlogan >>> >>> >>>> > http://erlware.org >>> >>> >>>> > >>> >>> >>>> > -- >>> >>> >>>> > You received this message because you are subscribed to the >>> >>> >>>> > Google >>> >>> >>>> > Groups "erlware-dev" group. >>> >>> >>>> > To post to this group, send email to >>> >>> >>>> > [email protected]. >>> >>> >>>> > To unsubscribe from this group, send email to >>> >>> >>>> > [email protected]. >>> >>> >>>> > For more options, visit this group at >>> >>> >>>> > http://groups.google.com/group/erlware-dev?hl=en. >>> >>> >>>> > >>> >>> >>>> > >>> >>> >>>> >>> >>> >>>> -- >>> >>> >>>> You received this message because you are subscribed to the >>> >>> >>>> Google >>> >>> Groups >>> >>> >>>> "erlware-dev" group. >>> >>> >>>> To post to this group, send email to >>> >>> >>>> [email protected]. >>> >>> >>>> To unsubscribe from this group, send email to >>> >>> >>>> [email protected]. >>> >>> >>>> For more options, visit this group at >>> >>> >>>> http://groups.google.com/group/erlware-dev?hl=en. >>> >>> >>>> >>> >>> >>> >>> >>> >>> -- >>> >>> >>> You received this message because you are subscribed to the Google >>> >>> Groups >>> >>> >>> "erlware-dev" group. >>> >>> >>> To post to this group, send email to [email protected]. >>> >>> >>> To unsubscribe from this group, send email to >>> >>> >>> [email protected]. >>> >>> >>> For more options, visit this group at >>> >>> >>> http://groups.google.com/group/erlware-dev?hl=en. >>> >>> >>> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> -- >>> >>> >> Martin Logan >>> >>> >> Erlang & OTP in Action (Manning) http://manning.com/logan >>> >>> >> http://twitter.com/martinjlogan >>> >>> >> http://erlware.org >>> >>> >> >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Martin Logan >>> >>> Erlang & OTP in Action (Manning) http://manning.com/logan >>> >>> http://twitter.com/martinjlogan >>> >>> http://erlware.org >>> >>> >>> >> >>> >> >> >> > > > > -- > Martin Logan > Erlang & OTP in Action (Manning) http://manning.com/logan > http://twitter.com/martinjlogan > http://erlware.org > -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
