K-user mailing list

[Stefan Ciobaca <stefan.ciobaca AT gmail.com>]

This would be nice and it will probably give us more visibility, but
we should agree on a naming scheme. Do you have any suggestions?

Cheers,
Stefan

On Tue, Jul 31, 2012 at 11:27 AM, Patrick Meredith 
<pmeredit AT gmail.com>
 wrote:
> A lot of the big companies are going to naming releases, e.g., big cats for
> OS X or deserts for Android.
>
> I think a naming scheme would be nice here.
>
> -P
>
>
> On Tue, Jul 31, 2012 at 2:56 AM, Stefan Ciobaca 
> <stefan.ciobaca AT gmail.com>
> wrote:
>>
>> I believe that Raluca has written down a summary of the meetings which
>> is available on the FMSE website.
>>
>> Andrei's proposal was to have releases for K in order to offer third
>> parties stable versions of K which are well-tested. Currently, the
>> latest branch might contain features which break compatibility without
>> being documented (and therefore frustrating third parties). We decided
>> that this is a good idea and here is how we want to implement it:
>>
>> The idea is to make K releases by *tagging* them in svn (a tag is
>> similar to a branch). We will make this tag whenever the code is
>> stable and we decide we want to release to third parties. The tag
>> essentially gives a name to a snapshot of the "latest" branch,
>> snapshot which is also uploaded on the k-framework.org/KVM, we write
>> an announcement for a new available version on k-user, etc.
>>
>> The workflow for K developers will not change much:
>>
>> - As before, the idea is to continue to commit into trunk. At every
>> commit into trunk, Jenkins automatically runs the tests and if none
>> fail, trunk is automatically merged into latest. For regular use, for
>> giving presentations, for research use, etc, the idea is to use
>> latest.
>>
>> - Here's what changes: every few months or so, whenever "latest" has
>> been tested for a while and we decide it's good enough, we *tag* it as
>> Release_n (where n is the release number). Release_n therefore refers
>> to the code snapshot at that particular time. We upload Release_n on
>> k-framework.org, we write an announcement on k_user with the new
>> features, etc. While users use Release_n, we continue to develop as
>> usual on trunk/latest; third parties do not see the changes until we
>> tag Release_{n+1}.
>>
>> - If a (serios) bug is reported for Release_n, we fix it immediately
>> in the branch Release_n and we release the fix to the public as an
>> important update to Release_n with an announcement on k_user. We also
>> merge the fix from this branch back into trunk.
>>
>> - If a bug which is reported is not very serios, we only need to
>> provide a workaround and we fix it directly in trunk, with the bugfix
>> becoming available in Release_{n+1}.
>>
>> Please let us know if you have any suggestions on this.
>>
>> Cheers,
>> Stefan
>>
>> On Tue, Jul 31, 2012 at 10:10 AM, Rosu, Grigore 
>> <grosu AT illinois.edu>
>> wrote:
>> > Yesterday we discussed the transition to K3 on the k-framework
>> > website(s).  There were some proposals on how to do the transition 
>> > smoothly
>> > and how to better maintain K from now on.  Andrei (A) or Stefan, can you
>> > please give everybody on the K list a brief survey of what we discussed?
>> > Also, I would like to make the transition asap, definitely before the
>> > classes start at UIUC (I will teach CS422 again in Fall).
>> >
>> > Cheers,
>> > Grigore
>> >
>> >
>> >
>> > _______________________________________________
>> > k-list mailing list
>> > k-list AT cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/k-list
>>
>> _______________________________________________
>> k-list mailing list
>> k-list AT cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/k-list
>
>
>
>
> --
> -Patrick