Skip to Content.
Sympa Menu

k-user - Re: [K-user] [k-list] K3 transition

k-user AT lists.cs.illinois.edu

Subject: K-user mailing list

List archive

Re: [K-user] [k-list] K3 transition


Chronological Thread 
  • From: Traian Florin Șerbănuță <traian.serbanuta AT info.uaic.ro>
  • To: Stefan Ciobaca <stefan.ciobaca AT gmail.com>
  • Cc: "k-user AT cs.uiuc.edu" <k-user AT cs.uiuc.edu>
  • Subject: Re: [K-user] [k-list] K3 transition
  • Date: Fri, 3 Aug 2012 00:03:28 +0300
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/k-user>
  • List-id: <k-user.cs.uiuc.edu>

The current tags are:

v2.0 v2.1 v2.2 v2.3 v2.4 v2.5 v2.6

I would suggest having
v3.0, v3.1, ...
and if we find and fix bugs, we can have v3.1.1, v3.1.2, ....

best wishes,
- traian

2012/7/31 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
> _______________________________________________
> k-user mailing list
> k-user AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/k-user



  • Re: [K-user] [k-list] K3 transition, Traian Florin Șerbănuță, 08/02/2012

Archive powered by MHonArc 2.6.16.

Top of Page